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.
- 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.
- 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.
- 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.
03 Apr 11 Single Responsibility Pattern
The single responsibility pattern states that a class should have one responsibility and one responsibility only. The resulting code, if this pattern is followed, is cleaner or more maintainable. What every class does is abundantly clear and the location of bugs is less of a daunting task.
How do you define a responsibility? Where does one end and another begin. These are nebulous questions to which there are no definitive answers, but that does not mean that this whole discussion is moot.
A violation of the single responsibility pattern is like pornography. You can't define it, but you know it when you see it. Experienced architects know what a class that has one responsibility looks like, so they have an instinctual sense of how to design their classes. Not everyone's an experienced software architect. What's the point of going over all of this for that type of person?
The point is to make those who are less experience aware of a way of thinking about design. If you're actively making each class have one responsibility, then you'll eventually learn to spot classes that egregiously violate that principle. As you design software over your career, that skill will lead to better quality.
I've won you over, but you may be thinking: can you give me an example? Let's consider something fairly straightforward: an email class. It fits the single responsibility principle, but that responsibility is quite sizable. Separating the content from the email makes the email class more focused. Still better the senders and receivers could be separated out too. The redesigned email class now extends two interfaces: one for the transportation points and the other for the content. Those are the sorts of decisions and thought patterns that the single responsibility principle imparts to you.
Source Code: click this link
