Agile Software Development Book Review

Desirable Characteristics of Application Design - Design Smells of Rotting Software - GRASP Patterns - Object-Oriented Principles

Dave Hayden — Tue, 09 Aug 2005 19:02:00 GMT

I think that most developers these days often have to play the role of architect. They are not only responsible for coding, but also responsible for the overall design of the application. Hence, we find ourselves putting on several hats during various phases and iterations of a project.

This is okay by me given that more and more companies are embracing agile software development. I find that I am focusing more on those tasks that lead to better applications in less time as opposed to paperwork and communication that only appease management and have little real-world value.

As “architects”, we need to understand characteristics of good application design. We need to follow proven principles and best practices that are language and development enviroment agnostic. If nothing else, we need to sound like we know what the hell we are talking about ;)

In several posts I have mentioned the application design smells of rotting software, which are unfavorable characteristics of an application (i.e. things you don't want):

Rigidity - System is hard to change.
Fragility - Changes causes system to break easily and require other changes.
Immobility - Difficult to entangle components that can be reused in other systems.
Viscosity - Doing things right is harder than doing things wrong.
Needless Complexity - System contains infrastructure that has no direct benefit.
Needless Repetition - Repeated structures that should have a single abstraction.
Opacity - Code is hard to understand.

I have also mentioned my ever favorite GRASP Patterns from Applying UML and Design Patterns - An Introduction to Object-Oriented Analysis and Design and Iterative Development by Craig Larman, which are useful as a learning aid for OO design with responsibilities:

Information Expert - A general principal of object design and responsibility assignment?
Creator - Who creates?
Controller - What first object beyond the UI layer receives and coordinates a system operation?
Low Coupling - How to reduce the impact of change?
High Cohesion - How to keep objects focused, understandable, and manageable?
Polymorphism - Who is responsible when behavior varies by type?
Pure Fabrication - Who is responsible when you are desperate, and do not want to violate high cohesion and low coupling?
Indirection - How to assign responsibilities to avoid direct coupling?
Protected Variations - How to assign responsibilities so that the variations or instability in the elements do not have an undesirable impact on other elements?

I also described a chapter of Code Complete 2 that mentioned several desirable characteristics of a design:

Minimal complexity - Avoid making “clever“ designs. Clever designs are usually hard to understand. Keep it simple.
Ease of maintenance
Loose coupling - Loose coupling means designing so that you hold connections among different parts of a program to a minimum.
Extensability - You should be able to change a piece of the system without causing a huge impact to other pieces of the system.
Reusability
High fan-in - Refers to having a high number of classes that use a given class. High fan-in implies that a system has been designed to make good use of utilitity classes at the lower levels in the system.
Low-to-medium fan-out - A given class should use a low-to-medium number of other classes. High fan-out (more than about seven) indicates a class uses a large number of other classes and may be overly complex.
Portability
Leanness
Stratification - Try to keep the levels of decomposition stratified so you can view the system at any single level without dipping into other levels.
Standard techniques - Give the whole system a familiar feeling by using standardized, common approaches.

And last, I talked about several Object-Oriented Principles from my Agile Software Development Principles, Patterns, and Practices Book Review:

Single-Responsibility Principle : A class should have only one reason to change.
Open-Closed Principle : Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.
The Liskov Substitution Principle : What is wanted is something like the following substitution property: If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2, then S is a subtype of T.
Dependency-Inversion Principle : A. High-level modules should not depend on low-level modules. Both should depend on abstractions. B. Abstractions should not depend on details. Details should depend on abstractions.
Interface-Segregation Principle : Clients should not be forced to depend on methods that they do not use.

As I look back at all of this conceptual information, I see a consitency. Actually, I see a redundancy where all of these books are talking about the same principles of good application design in their own way. I find this great and really enjoy the reinforcement, because it helps me when I need to put on that “architect” hat. I can speak and think with confidence with respect to all the authors who have much more experience on these subjects than myself.

Keep this list handy as I hope it will be useful when you need to think about the design and architecture of your next application.

Resources

David Hayden ( Sarasota Web Design / Blog )

Drinking: Dragon Well Lung Ching Green Tea

Objections to Agile Development White Paper - Awesome!

Dave Hayden — Fri, 29 Jul 2005 17:47:00 GMT

If you do nothing else this weekend :), I highly recommend one read Jim Highsmith's white paper, called Objections to Agile Development. I just finished reading the white paper, and it is awesome! Don't even waste your time trying to mark it up with a highlighter, because the entire white paper is packed with great information.

On Ad Hoc Development

Jim coins a new term for me, called Ad Hoc Development, which is essentially the practice by some developers to get out of all design, documentation, modeling, etc. and label it Agile Development. Cool term.

“There is still a contingent of people who believe that agile development is an excuse to be ad hoc and undisciplined. However, technical excellence is a tenet of all agile approaches. When a code base has automated tests, is refined to maintain quality as the project proceeds, is continuously integrated, and so on, it is very difficult to label the results as poor quality.“ - Jim Highsmith

On Architectural and Design Excellence

“Agile approaches actually encourage — in fact, demand — architectural and design excellence. Technical excellence is a fundamental principle of agile development. Technical excellence is obtained through the application of four key practices: ruthless testing, refactoring, simple design, and continuous integration. These four practices work together to ensure that the design is always simple, robust, and adaptable; that the code is constantly of high quality because of extensive automated testing; that the designs are constantly upgraded through refactoring as new functionality is added; and that the entire system is constantly integrated and reviewed by customers and technical staffs. All software goes though these cycles; agile developers just do them constantly in short iterations. These cycle practices keep the cost of change (iteration cost) down, in turn allowing emergent design processes to work effectively.“ - Jim Highsmith

On Iterative Design

“Iterative design (or architecture) therefore isn’t lack of design, it’s different design — and, in fact, iterative design often yields much better designs because the designs are subjected to reality testing and copious feedback. The key to this design approach is low-cost iteration, which agile software development strives for.” - Jim Highsmith

On Documentation

“Agile methods advocate simple, effective, low-ceremony, barely sufficient, less-formal documentation — but that’s a far cry from no documentation. Maybe some people don’t consider story cards, whiteboard sketches, or flipchart drawings to be documentation. If so, they are missing the essence of what documentation can accomplish.” - Jim Highsmith

“I’ve never met a manager who didn’t profess the need for documentation for maintenance and enhancements, and I’ve never talked to a programmer who used much more than the existing code. That doesn’t mean that some high-level documentation isn’t useful; it just means that most organizations have been very ineffective with the money they have spent on documentation.” - Jim Highsmith

On Modeling

“Agile developers aren’t antimodeling, but they are anticompliance modeling. Modeling that directly contributes to delivering working software will be used by agile developers.“ - Jim Highsmith

Conclusion

Phenomenal white paper. Download it here. Thanks, Jim.

David Hayden ( Sarasota Web Design / Blog )

Drinking: Gyokuro Green Tea

Listening To: Desert Rose by Sting

Strategy Design Pattern and Open-Closed Principle

Dave Hayden — Fri, 01 Jul 2005 17:22:00 GMT

Summary

This post describes how the Strategy Design Pattern lets a variety of different algorithms be used interchangeably as well as how it relates to the Open-Closed Principle. You can read my previous article discussing the Strategy Design Pattern and Dependency-Inversion Principle. Some information is repeated here on purpose from the previous article, because it shows how the Strategy Design Pattern helps your applications implement several object-oriented principles.

Open-Closed Principle

In a recent post I talked about the Open-Closed Principle as discussed in the the book, Agile Software Development - Principles, Patterns, and Practices by Robert Martin. The Open-Closed Principle is one of five object-oriented programming principles associated with class design:

Open-Closed Principle

"Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification [Martin, p.99]"

Modules that adhere to this Open-Closed Principle have 2 primary attributes:

"Open For Extension" - It is possible to extend the behavior of the module as the requirements of the application change (i.e. change the behavior of the module).
"Closed For Modification" - Extending the behavior of the module does not result in the changing of the source code or binary code of the module itself.

How This Relates to the Strategy Design Pattern

As discussed earlier with the Dependency-Inversion Principle, two design patterns that can help you implement the Open-Closed Principle in your applications are the Template Method and Strategy Design Patterns. These two design patterns are all about hiding the specifics of an algorithm either via Inheritance (Template Method) or delegation (Strategy Pattern).

The Strategy Design Pattern delegates algorithm specifics via an Interface.

Example of Strategy Pattern in the .NET Framework

A great example of the Strategy Pattern in the .NET Framework is the sorting of objects in an ArrayList via the IComparer Interface.

By default, the Sort method on ArrayList uses the QuickSort algorithm along with the IComparable implementation of each item in the list for sorting.

However, at times it may be necessary to sort the list in different ways. To accomplish this, there is an overload of Sort that takes an IComparer as a parameter. If used, ArrayList uses IComparer.Compare for the comparisons. By passing in an object that implements IComparer, the ArrayList can implement other sorting methods without caring about the details of the comparison method.

This is an example of the Strategy Design Pattern. Hiding the details of the comparison method behind an Interface allows the algorithm to vary and keeps the ArrayList from being dependant on the classes that implement such algorithms.

Strategy Pattern with IComparer

class CoolComparer : IComparer
{
    #region IComparer Members

    public int Compare(object x, object y)
    {
        // TODO:  implementation
        return 0;
    }

    #endregion

}


ArrayList items = new ArrayList();

items.Add("One");
items.Add("Two");
items.Add("Three");

items.Sort(); // Uses IComparable on string object

IComparer myComparer = new CoolComparer();
items.Sort(myComparer); // Delegate Comparison Method

How This Relates to the Open-Closed Principle

This supports the Open-Closed Principle because implementing a new comparison method for sorting objects in an ArrayList does not require a change to the ArrayList Class. This class is essentially closed for modification. However, because we can pass in an object that implements IComparer, the class is open for extension. Extending this class only requires new code ( classes ) to be written that implement IComparer, not changes to existing code.

Conclusion

The Strategy Design Pattern is a pretty powerful and often used design pattern to loosely couple your main classes in an application from lower-level detail classes / algorithms. As with all design patterns, it is best not to use them just for the sake of using them, because you will run the risk of needless complexity (application design smells) in your applications. They are best thought of as a solution to a real problem that occurs during refactoring and a method of communicating how the problem was solved.

Strategy Design Pattern and Dependency-Inversion Principle

Dave Hayden — Mon, 27 Jun 2005 19:54:00 GMT

Summary

This post describes how the Strategy Design Pattern lets a variety of different algorithms be used interchangeably as well as how it relates to the Dependency-Inversion Principle.

Dependency-Inversion Principle

In a recent post I talked about the Dependency-Inversion Principle discussed in the the book, Agile Software Development - Principles, Patterns, and Practices by Robert Martin. The Dependency-Inversion Principle is one of five object-oriented programming principles associated with class design:

Dependency-Inversion Principle

A. High-level modules should not depend on low-level modules. Both should depend on abstractions.
B. Abstractions should not depend on details. Details should depend on abstractions.

The principle suggests you can make your applications loosely coupled (Low Coupling GRASP Pattern) by not depending on concrete classes, but abstractions. This principle points out the direction of dependency on the abstraction. Rather than having the policy and business level classes dependent on the lower-level plumbing / utility type detail classes, it recommends that you invert the dependency and make the lower-level detail classes dependent on the higher level policy making classes that are most important in your application (via an abstraction).

How This Relates to the Strategy Design Pattern

Two design patterns that can help you implement the Dependency-Inversion Principle in your applications are the Template Method and Strategy Design Patterns. These two design patterns are all about hiding the specifics of an algorithm either via Inheritance (Template Method) or delegation (Strategy Pattern).

The Strategy Design Pattern delegates algorithm specifics via an Interface.

Example of Strategy Pattern in the .NET Framework

A great example of the Strategy Pattern in the .NET Framework is the sorting of objects in an ArrayList via the IComparer Interface.

By default, the Sort method on ArrayList uses the QuickSort algorithm along with the IComparable implementation of each item in the list for sorting.

Strategy Pattern with IComparer

class CoolComparer : IComparer
{
    #region IComparer Members

    public int Compare(object x, object y)
    {
        // TODO:  implementation
        return 0;
    }

    #endregion

}


ArrayList items = new ArrayList();

items.Add("One");
items.Add("Two");
items.Add("Three");

items.Sort(); // Uses IComparable on string object

IComparer myComparer = new CoolComparer();
items.Sort(myComparer); // Delegate Comparison Method

Conclusion

Agile Software Development Principles, Patterns, and Practices Book Review Conclusion

Dave Hayden — Fri, 17 Jun 2005 13:40:00 GMT

This post concludes my chapter-by-chapter review of Agile Software Development Principles, Patterns, and Practices by Robert Martin. Although I have barely scratched the surface of the book in terms of posts and it certainly contains much more information (and more chapters) than I have presented in my review, I want to wrap this review up with the following comments below.

Agile Software Development, Principles, Patterns, and Practices

Book: Agile Software Development, Principles, Patterns, and Practices (Amazon)
Author: Robert C. Martin (Amazon)
Publisher: Prentice Hall; 1st edition (October 15, 2002)
Hardcover: 552 pages

Previous Chapters

What I Didn't Cover

I didn't cover all the cool design patterns that Robert discusses in more detail and how they relate to the five Object-Oriented Programming Class Design Principles mentioned above in Chapters 8 - 12. Robert does an excellent job of describing the following design patterns and the rational behind them:

Command and Active Object
Template Method and Strategy
Facade and Mediator
Singleton and Monostate
Null Object
Factory
Composite
Observer
Abstract Server, Adapter, and Bridge
Proxy and Stairway to Heaven
Visitor
State

He also shows the design patterns being used in 3 case studies: Payroll Case Study, Weather Station Case Study, and an ETS Case Study.

Conclusion

Robert's book is an excellent introduction to object-oriented programming principles, design patterns, and how the theory can be used in a real application and application framework. The information is well laid out in a logical and comfortable style. Chapters can be easily digested in one-hour increments. This is a good book for intermediate and expert developers. Beginners with a bit of OOP experience will also benefit from reading the book. For someone who hasn't done any OOP at all, I am sure there are easier books to start out with.

The code examples are in java and C++, so you won't find any C# or VB.NET examples and absolutely no mention of anything .NET related. If you don't feel comfortable with looking at java or C++ syntax, I still think the book is a great buy with just the theory alone. However, the code samples could definitely be improved, and they are certainly not one of the book's strengths. If Robert came out with VB.NET and C# versions of the book, this book would be a must buy in my opinion.

Book Resources

Recommended Companion Book

Applying UML and Design Patterns - An Introduction to Object-Oriented Analysis and Design and Iterative Development by Craig Larman

Recommended Reading

MSDN Magazine July 2005 Article: Discover the Design Patterns You're Already Using in the .NET Framework
The Value of Agile Methods - Slide Deck by Howard van Rooijen of conchango
PatternShare
How to Use Design Patterns - A Conversation with Erich Gamma

Interface-Segregation Principle (ISP) - Principles of Object-Oriented Design - Chapter 12 - Agile Software Development

Dave Hayden — Wed, 15 Jun 2005 11:25:00 GMT

This post describes the last of the 5 Class Design Principles associated with the Principles of Object-Oriented Design. You can read all the posts from my chapter-by-chapter review of Agile Software Development Principles, Patterns, and Practices by Robert Martin.

Agile Software Development, Principles, Patterns, and Practices

Previous Chapters

Chapter 12 is on the Interface-Segregation Principle (ISP):

Interface-Segregation Principle

Clients should not be forced to depend on methods that they do not use.

This principle is very much related to the High Cohesion GRASP Pattern

High Cohesion GRASP Pattern - how strongly related and focused the responsibilities of an object are

The Interface-Segregation Principle focuses on the cohesiveness of interfaces with respect to the clients that use them. Here are some other descriptions I found while Googling:

“Many client specific interfaces are better than one general purpose interface“
“The dependency of one class to another one should depend on the smallest possible interface“
“Make fine grained interfaces that are client specific.“
“Clients should not be forced to depend upon interfaces that they don’t use. This principle deals with the disadvantages of fat interfaces. Fat interfaces are not cohesive. In other words the interfaces of classes should be broken into groups of member functions.“

The idea here is that each client may use a particular object or subsystem in a different way. Take an inventory system for example. Your e-commerce website may only check on the inventory status of a product, but your order fulfillment system may both check on the status of a product as well as manipulate inventory levels. This suggests that you will probably want to have 1 interface for checking product inventory levels and another interface for manipulating inventory levels. This will keep each client independent of interfaces that they do not use. If you need to change one interface, you shouldn't need to change the other. As you create your application and identify the particular clients and user stories, these cohesive interfaces will become evident.

Robert had a couple examples of the Interface-Segregation Principle. The more interesting one was about an ATM, where it may logically stand to reason that you may have separate interefaces for a person conducting a 1) Deposit Transaction, 2) Withdrawal Transaction, and 3) Transfer Transaction. You would definitely separate these 3 interfaces from each other so that one type of transaction does not depend on functions it does not need.

You can read Robert's words about the Interface-Segregation Principle in this PDF.

The Dependency-Inversion Principle - Chapter 11 - Agile Software Development Principles Patterns and Practices

Dave Hayden — Fri, 10 Jun 2005 14:50:00 GMT

Moving along with my chapter-by-chapter review of Agile Software Development Principles, Patterns, and Practices by Robert Martin.

Agile Software Development, Principles, Patterns, and Practices

Previous Chapters

Chapter 11 is on the Dependency-Inversion Principle:

Dependency-Inversion Principle

A. High-level modules should not depend on low-level modules. Both should depend on abstractions.
B. Abstractions should not depend on details. Details should depend on abstractions.

This principle is closely related to two other principles that I have talked about previously:

Open-Closed Principle - Modules should be open for extension, but closed for modification.
Low Coupling GRASP Pattern - An element with low (or weak) coupling is not dependent on too many other elements.

All three of these principles have to do with making your applications loosely coupled by not depending on concrete classes when appropriate, but abstractions. These abstractions are usually done with abstract classes and interfaces. This book has tended to focus on abstract classes, but you can find other books that prefer interfaces, etc. There are pros and cons to each, and that subject is beyond the scope of this post :).

This principle is unique with respect to the others in that it points out the direction of dependency on the abstraction. Rather than having the policy and business level classes dependent on the lower-level plumbing / utility type detail classes, it recommends that you invert the dependency and make the lower-level detail classes dependent on the higher level policy making classes that are most important in your application (via an abstraction).

Robert said it best in this brief, well-written chunk of text from his book:

“Consider the implications of high level modules that depend upon low level modules. It is the high level modules that contain the important policy decisions and business models of an application. It is these models that contain the identity of the application. Yet, when these modules depend upon the lower level modules, then changes to the lower level modules can have direct effects upon them; and can force them to change.

This predicament is absurd! It is the high level modules that ought to be forcing the low level modules to change. It is the high level modules that should take precedence over the lower level modules. High level modules simply should not depend upon low level modules in any way.

Moreover, it is high level modules that we want to be able to reuse. We are already quite good at reusing low level modules in the form of subroutine libraries. When high level modules depend upon low level modules, it becomes very difficult to reuse those high level modules in different contexts. However, when the high level modules are independent of the low level modules, then the high level modules can be reused quite simply.[Martin, p.127-128]”

You can see this visually in the following figures:

This is a very, very common practice. Everything in the Enterprise Library Application Block uses this principle to make it pluggable so that you can add new caching strategies, data repositories, configuration policies, etc. It is also used in anything that uses the Provider Model, because this is the basis of the Provider Model - provide an abstraction in the .NET framework that your application can utilize and have components that provide the detail be dependent on that abstraction used in your application.

You can see my posts on DotNetNuke and Community Server for a little bit of information on the Provider Model - the pre .NET 2.0 version anyway, which I have used several times in applications:

You can read Robert's words about the Dependency-Inversion Principle in this PDF. A couple of chapters from now I will start digging into a lot of the Design Patterns that support these principles.

The Liskov Substitution Principle - Agile Software Development Principles Patterns and Practices

Dave Hayden — Fri, 10 Jun 2005 10:53:00 GMT

For the past few weeks I have been doing a chapter-by-chapter review of Agile Software Development Principles, Patterns, and Practices by Robert Martin. So far, it has covered a lot of good introductory information on various Agile Methodologies (Test-Driven Development, Refactoring, Pair Programming, Project Planning, Extreme Programming, etc.) as well as talked about various object-oriented programming principles, which is what I am still covering now.

Here is a chapter-by-chapter breakdown on what I have covered so far:

Agile Software Development, Principles, Patterns, and Practices

Previous Chapters

Chapter 10 is on the Liskov Substitution Principle:

Liskov Substitution Principle

“What is wanted is something like the following substitution property: If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2, then S is a subtype of T. [Liskov88]“

Is it me, or is that painful to read? Robert Martin puts it a bit simpler:

Subtypes must be substitutable for their base types

The classic example of this principle in code is inheriting the Square Class from the Rectangle Class.

Classic Example of LSP

public class Rectangle
{
    protected int _width;
    protected int _height;
    
    public int Width
    {
        get { return _width; }
    }
    
    public int Height
    {
        get { return _height; }
    }
    
    public virtual void SetWidth(int width)
    {
        _width = width;
    }
    
    public virtual void SetHeight(int height)
    {
        _height = height;
    }
}

public class Square: Rectangle
{
    public override void SetWidth(int width)
    {
        _width = width;
        _height = width;
    }
    
    public override void SetHeight(int height)
    {
        _height = height;
        _width = _height;
    }
}

[TestFixture]
public class RectangleTests
{
    [Test]
    public void AreaOfRectangle()
    {
        Rectangle r = new Square();
        
        r.Width = 5;
        r.Height = 2;
        
        // Will Fail - r is a square and sets
        // width and height equal to each other.
        Assert.IsEqual(r.Width * r.Height,10);
    }
}

If you look at the test above, it will fail because a square is being substituted for a rectangle and the area won't be 10 as expected. It will actually be 4 because “unexpectedly” in this case, both height and width are being set to each other when the width or height is set on a square. Therefore, if this behavior by Square is unacceptable and unexpected, Square should not be derived from Rectangle (at least not coded like this with these expectations anyway).

This is the whole point of the Liskov Substitution Principle. It basically wants you to think clearly about the expected behavior and expectations of a class before you derive new classes from it. It could turn out that when subtypes are substituted for a parent, you may get unexpected results. This is where unit tests can really be handy. The unit tests essentially describe and test for the expected behavior of objects (design by contract, if you will).

If you want to read some discussions as to the usefulness of this principle, whether it should be a principle, and thoughts on the classic example above, check out this wiki. You can also read what Robert Martin has to say about it from this PDF.

Open-Closed Principle (OCP) - Agile Software Development - Object-Oriented Principles and Software Development

Dave Hayden — Sat, 04 Jun 2005 20:15:00 GMT

It's been raining all week in Sarasota, Florida and all day long today. Perfect weather for playing inside with the kids, watching movies I would never normally watch, and sipping on green tea while reading a good book, Agile Software Development Principles, Patterns, and Practices, by Robert C. Martin (Amazon).

I have completed 9 chapters of this 30 chapter book and have enjoyed it tremendously. So far, I would highly recommend it for someone interested in reading about solid OOP principles and guidelines for developing software. I enjoy reading these good practices from a number of different books with different styles and examples because it helps reinforce the information as well as perhaps opens new insights.

Here are the chapters I have read so far:

Chapter 1 - 4: Agile Practices, Extreme Programming, and Test-Driven Development
Chapter 5 and 6: Refactoring and Pair Programming
Chapter 7: Agile Design
Chapter 8: Single-Responsibility Principle

Chapter 9 is on the Open-Closed Principle:

Open-Closed Principle

"Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification [Martin, p.99]"

The author goes on to explain that this principle encourages the developer to refactor (MSDN Refactoring Webcast) the software such that if enhancements or changes are required at a later time, it only requires the developer to add new code, not change exisiting code. This is a rather cool idea, because it means that maintaing software in the future should be easier as you don't have to worry as much about breaking existing code. Forgetting for a moment whether this notion is realistic or even achievable, it is a good thing to shoot for in your applications.

Robert Martin says modules that adhere to this Open-Closed Principle have 2 primary attributes:

"Open For Extension" - It is possible to extend the behavior of the module as the requirements of the application change (i.e. change the behavior of the module).
"Closed For Modification" - Extending the behavior of the module does not result in the changing of the source code or binary code of the module itself.

At first glance, these two attributes seem to be at odds. However, as I read further through the chapter, I realize he is referring to using Abstract Classes and their Concrete SubClasses to extend behavior. This essentially means using something like the Template Method Pattern or Strategy Pattern to delegate either part or all of an algorithm in a Concrete SubClass. The Template Method Pattern UML is shown below:

A Template Method is a Method in an (abstract) base class which calls one or more HookMethods to fulfill parts of its tasks. You can easily extend or change the behavior of the abstract base class by creating new subclasses that implement a new version of the Hook Method. This fulfills the requirements of the Open-Closed Principle.

Every good application is probably teeming with abstract base classes for this very thing, and I know of 3 open-source applications I have recently talked about where you can find it:

DotNetNuke - Provider model for the data access layer
Community Server - Provider model for the data access layer
Enterprise Library - Used in every application block to add new functionality.

Each of the open-source applications use modules supporting the Open-Closed Principle to allow them to plug either 1) a new data provider in the case of DotNetNuke and Community Server, or 2) a new caching strategy (as an example) for the Enterprise Library. This extensability is achieved using a pluggable architecture that uses reflection and configuration files, which is one way to achieve the "Open For Extension" but "Closed For Modifications" idea of the Open-Closed Principle.

Single-Responsibility Principle - Agile Software Development Principles Patterns and Practices

Dave Hayden — Sun, 29 May 2005 17:02:00 GMT

I am continuing my reading of Agile Software Development - Principles, Patterns, and Practices by Robert C. Martin (Amazon). Chapter 8 talks about the Single-Responsibility Principle:

Single-Responsibility Principle

A class should have only one reason to change.

As the chapter explains, the single-responsibility principle is more frequently known as cohesion (High Cohesion GRASP Pattern), which is the functional relatedness of the elements of a module. Basically, you want to keep classes, functions, etc. focused so that there is only one reason for them to change. This is the reason why many people separate their applications into layers, for example. The data access layer provides persistence and re-hydration of business objects. The business layer is all about business rules. And, the presentation layer is only about presenting information to the user. Hopefully a change in one layer won't cause a ripple effect of changes in other layers, or at least, keep the impact to a minimum.

Robert provides a couple of examples in the brief 3 page chapter. A popular example that "violates" this principle is placing persistence logic in your business classes. By doing so, you have 2 reasons for a business class to change. First, when you need to change the persistence logic, and second, when you need to change the business rules. Fowler describes this type of domain model as Active Record (details), and although it violates this principle, Active Record is successfully used in many applications. These principles are only guidelines and you have to weigh the pros and cons of following these guidelines as all of them impact time of delivery, cost, and maintainability.

However, the author reinforces that we should be thinking about "real" changes - focusing on things that most likely could change. If you don't see your data access logic changing, then Active Record may not be violating this principle at all. So many people build their applications so that they can switch databases, swich persistence logic, etc., but in reality this may not happen. So, when we look at these axis of change for a particular class, function, layer, etc., the author stresses to only focus on those pieces that really could change.

A good example of sticking to this principle could be found in an off-the-shelf, e-commerce application. When calculating shipping costs on a particular sale, the developers of the e-commerce application don't want the Sale class calculating shipping costs. Each online store has their own rules for calculating shipping costs on a sale, and the developers would want shipping costs calculated by a separate class that contains the business rules for each store. By placing shipping calculations in a separate class, the Sale class does not have to change everytime the shipping calculations change. As a result, shipping calculations are usually placed in separate, pluggable classes that implement the Strategy Pattern.

So far, the book is excellent and you might be interesting in reading about other chapters:

As I mentioned before, you can read about this principle here on the author's website.