POODR - Ch2: Designing Classes with a Single Responsibility
22 Apr 2015The foundation of an object-orietned is the message, but most visible organizational structure is the class.
OO Questions:
What are your classes? How many should you have? What behavior will they implement? How much do they know about the other classes? How much of themselves should the expose?
At this stage, your first obligation is to take a deep breath and insist that it be simple. Your goal is to model your application, using classes, such that is does what is is supposed to do right now. Design is more the art of perserving changability than it is the act of achieving perfection.
Code should be TRUE:
Transparent: The consquences of change should be obvious in the code that is changing and in distant code thst relies on it.
Reasonsable: The cost of any change should be proportional to the benefit thr change acheives
Usable: Existing code should be usable in a new and unexpected contents.
Expemplary: The cod itself should encourage those who change it to perpetuate these qualities. TRUE ensures that each class has a single, well-defined responsibilty.
Creating Classes That have a Single Responsibility
A class should do the smallest posbbile useful thing, that is - it should have a sing responsibility.
Why Single Responsibility Matters
Appliciations that are easy to change consist of classes that are easy to reuse. Reusable classes are pluggable into units of well-defined behavior that have few entanglements.
A class that has more than one responsibility is difficult to reuse. If you want to resuse some (but not all) of it behavior, it is impossible to get only the parts you need.
If the responsibilties are so coupled that you cannot use just the beviour you need, you could duplicat the code of interest.
Deterimining If a Class Has Single Responsibility
How can you determine if a class contains the behavior or belongs somewhere else? Ask it! "Mr Gear, What is your ratio?"
Another way to figure it out is to attempt to describe the class in one sentence. If the simplest description you can devise includes "and", the class likely has more than one responsibility. If the description includes "or", then the class has more than one responsibility and they aren't even related.
When a class is related to it's purpose, its considered "highly cohesive" or to have single responsibility (Single Responsibility Principle)
Determining when to make design decisions:
Don't feel compelled to make design decisions prematurely. When the future cost of doing nothing is the same as the current cost, postpone the decision. Make the decision only when you must with the information you have at the time.
Writing Code that Embraces Change
Here are a few well known techniques that you can use to create code that embaces change:
1. Depend on Behavior, not Data
Behavior is captured in methods anid invoked by sending messages. In addition to behavior, objects often contain data. Data is held in an instance variable and can be anything from an simple string to complex hash. Data can be accessed in 2 ways: 1. you can refer directly to the instance variable 2. you can wrap the intance variable in an accessor method
Hide Data Structures
1. Always wrap instance variables in accessor methods insteadof directly referring to the variables
2. Use Structs
Direct references into complicated structure are confusing, because they obscure what the data really is and the maintenance is a nightmare. In Ruby, it's easy to seperate structure from meaning - just as you use a method to wrap an instance variable, you can use a Ruby Struct class to wrap a structure. Ruby defines Struct as "a convenient way to bundle a number of attributes together, using accessor methods, without having to write an explicit class.
2. Enforce Single Responsibilities Everywhere
3. Extract Extra Responsibilities from Methods
Methods, like classes should have single responsibility so they are easier to use. Apply the same design techniques as you would with classes.
- Seperating iteration from the action that's being performed on each element is a common case of multiple responsibitlity that is easy to recognize.
The imapct of the single refactoring like ithis is small, but the cumulative effect of this coding style is huge. Methods that have single resonsibility confer the following benefits:
1. Expose previously hidden qualities
2. Avoid the need for comments
3. Encourage reuse
4. Easy to move to another class
Isolate Extra Responsibilities in Classes
Once every method has a single responsibility, the scope of your class will be more apparent
The path to changeable and maintable object oriented software begins with classes that have a single responsibility. Classes that do one thing isolate that thing from the rest of your application. This isolation allows change without consquence and reuse without duplication.