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.
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.
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