Recapping Need For Oo Design And Making Sure Classes Have A Single Responsibility
The first requirement for learning how to do object-oriented design is to immerse yourself in objects; Once you acquire an object-oriented perspective the rest follows naturally.
We need object-oriented design so that we can write code for today that is easy to change later, because change is inevitable.
OOD is about arranging what code you have so that it will be easy to change.
An object-oriented designer has tools, principles (SOLID, DRY, LoD) and patterns (common problems solved in common ways).
Design is worth it if it pays off (e.g. if it takes half your time in the morning but pays off in the afternoon).
Insist that it be simple. Your goal is to model your application using classes so that it does what it is supposed to do right now, and is easy to change later.
It’s impossible correctly group methods into the right classes at the early stage of your project. You don’t know enough. So the only goal is to make things easy to change.
A class should do the smallest possible useful thing; It should have a single responsibility.
- Look through the description and look for nouns that represent objects in your domain.
- Objects are those that have both data and behaviour.
- Determine if a class has a single responsibility by rephrasing each of its methods as a question “Please Mr. Gear, what is your ratio?”
- Or, describe the class in one sentence, if it has an “and” or an “or”, it’s doing other people’s work.
- Depend on behaviour, not data. Every tiny bit of behaviour lives in only one place.
- Hide instance variables by wrapping them in accessor methods (never directly refer to them, even in the class they belong to).
- Hide data structures. You can use the Ruby Struct class to wrap a structure.
An application that is easy to change is like a box of building blocks; you can select just the pieces you need and assemble them in unanticipated ways.