17 Apr 12 Basics Rules for Object-Oriented Design: Single Responsibility Principle

This entry extends the one about object-oriented design.   Unlike the broad focus of that article, this one focuses on a more specific topic – the Single Responsible Principle (SRP).  However, SRP is too broad a topic to be discussed pithily.  As a result, the subsequent article focuses on the more parochial topic, implementing SRP in a simple way.  As a means for achieving that goal, tips are provided by the list below. The implementation of those tips is demonstrated by the accompanying code.

1. One can use base classes to separate responsibilities.  When a class extends another class, it inherits its base-class’s functionality.  Consequently, the inheriting class necessarily avoids implementing its base-class’s functionality.  Inheritance allows the functionality of the two classes to remain separated.  The previous article on object-oriented design demonstrates this principle nicely.
2. With the exception of library classes, most classes contain data.  One can separate that data from its containing class to achieve SRP.  However, achieving that separation can involve a myriad of strategies – a topic that rightly deserves its own article – but the means by which data can be separated from its containing class is not particularly germane to the topic at hand.  The more relevant, and salient, point to take away from this tip is the concept that one should separate, when reasonable, a class’s data from the class itself.
3. With the exception of data containers, classes have functionality.  One can separate the handling of that functionality from the functionality’s containing class to achieve SRP.  Similar to separating data, achieving the formerly described separation can involve a myriad of strategies, but the specifics of those strategies are ungermane to this article.  The more relevant, and salient, point to take away from this tip is the concept that one should separate, when reasonable, a class’s handling of its functionality.

The aforementioned tips are not a formula.  Occasionally, the preceding tips might not be prudent to use, so one must implement them judiciously.  However, do not become too hung up on that caveat.  If one uses a tip injudiciously, at some point the affects of that misuse should become apparent.  Even if the point of that discovery is at an inopportune time, the windfall of such a discovery does teach valuable lessons – ones that are often not forgotten.  As a result, feel free to make mistakes.  However, one must still be mindful of the aforementioned caveat, as judiciousness must always be exercised when designing software.