Single Responsibility Principle
There should never be more than one reason for a class or method to change. Every component of code should perform a single well defined task.
If a component has more then one responsibility then those responsibilities become coupled and you can’t change one without impacting the other. This will lead to fragile software that breaks in unexpected ways when you change it.
This is one of the hardest things to do as we naturally combine responsibilities. A large amount of your design effort will be to identify and then separate responsibilities.
What is a responsibility? A responsibility is also known as a purpose. For each component, ask yourself what is the specific purpose of this component? This is actually a question you will keep needing to ask yourself as you revisit existing components. Code changes and evolves over time and what used to have a single purpose might now have multiple purposes and need refactoring.
Here are some benefits to following this principle
- Reduced code Complexity,
- Clearer code,
- Increased readability of your code,
- reduced Coupling,
- Code is easier to change and evolve
For example: If your component (class/function) can be forced to changed through both business rule change and a data model change then you have identified a component that needs to be separated into two components. One that changes as business rules change but is not impacted by data model changes and one that changes as the data model changes but is not impacted by business rule changes.
References
http://www.artima.com/weblogs/viewpost.jsp?thread=331531
http://www.objectmentor.com/resources/articles/srp.pdf
http://codebetter.com/karlseguin/2008/12/05/get-solid-single-responsibility-principle/
http://en.wikipedia.org/wiki/Single_responsibility_principle
Write Code For The Maintainer
Maintenance is by far the most expensive phase of any project. The best return on investment is any work done to reduce the ongoing maintenance cost of your software.
The best quote I’ve found for this is from http://c2.com/cgi/wiki?CodeForTheMaintainer
from the same page an alternative quote
Remember that while you will know what you are doing when writing the software, it is the next guy who needs the helping hand.
Maintainability of code is a very subjective opinion, 3 people can look at the same code and think it is very maintainable or bloated or cryptic. Each opinion being a valid one.
Verbose code is not more maintainable. You want succinct code that is clear and easy to read. It takes time to read and understand the extra lines of code. Each extra line is another potential source of bugs. So less is more.
At the other end of the spectrum don’t shrink the code down to the point that it becomes obfuscated.
Which is easier to read?
or
A little bit of verbosity does help with the readability of your code from a maintenance point of view. You want to tread the line in the middle where your code is a pleasure to read.
Comments – if your comments are simply narrating the code don’t bother putting them in. The best value comments are those which explain why your code does what it does – they explain the rationale behind what you are doing.
Maintainability doesn’t mean obvious and basic. Assume that the person maintaining your code will be just as smart as you. Just write your code as you would want it if you were going to maintain it.
An interesting bit of trivia, Hungarian notation violates the “Once and Only Once” principle by recording the type of the variable in the declaration and in the variable name – the type of a variable can change and if you don’t line up the name again you can end up with “String iNotAnIntAnyMore” somewhere in your code.
References
http://www.artima.com/weblogs/viewpost.jsp?thread=331531
http://c2.com/cgi/wiki?CodeForTheMaintainer
http://www.perlmonks.org/?node_id=727817
http://www.codinghorror.com/blog/2008/06/coding-for-violent-psychopaths.html
Maintainability
Maintenance
Programming Principle
Verbose Code
Comments
hungarian notation
Maintainability
Maintenance
programming principle
readability
Verbose Code
Write Code For The Maintainer