The Pragmatic Craftsman         :: Simplicity from complexity :: | About Me |

A fairly common occurence I've come across in software development is that a class I'm working on
changes for various non-related reasons. For one type of change, I modify a portion of it, and for another, another portion. That's not a good situation.

Martin Fowler calls this "divergent change" under the Code Smells category. He says the
following,

"Programs should be structured in such a way that we can make changes easily. When we make a change we want to be able to jump to a single clear point in the system and make the change.

Divergent change occurs when one class is commonly changed in different ways for different reasons. If
you look at the class and say, "Well, I will have to change these three methods every time I get a new database; I have to change these four methods every time there is a new financial instrument," you likely have a situation in which two objects are better than one. That way each object is changed only as a result of one kind of change."

Robert Martin calls this principle The Single-Responsibility Principle: A class should have only one reason to change.

In this context, he defines responsibility as "a reason for change." If you can think of more than one motive for changing a class, then that class has more than one responsibility. "It's not easy to see that because we usually think of responsibilites in groups."

What's an example of a responsibility coupling? Martin gives a common violation of the SRP: Employee class containing business rules and persistence control. Business rules tend to change frequently, and persistence usually changes for completely different reasons. A clear violation.

Interestingly, Martin calls this principle one of the simplest, and at the same time, one of the hardest to get right. "Conjoining responsibilities is something that we do naturally. Finding and seperating those responsibilites from one another is much of what software design is really about."

Thus, when adding new functionality to a class, I think it's important to keep in mind that they don't violate the Single-Responsibilty Principle. This has a side effect of keeping your classes cohesive. And you know
that is a good thing.

Once again, if over time you make changes to a class that touch completely different parts of the class, you have a violation of the principle. Split the class in two. Put the parts that change together into their own class. You'll be glad that you did. :-)

Reference

More Info on SRP
Single-Responsibility principle is a fundamental principle in software design. It is a good idea to
"embed" it into your software development knowledge. http://www.objectmentor.com/resources/articles/srp

Refactoring, Martin Fowler's influential and still relative book on refactoring (Code Smells section is invaluable).

Agile Software Development, Robert Martin's book on patterns, a great book. He talks about fundamental patterns in OO development. A must read.