Home

POODR Notes

1. Object-Oriented Design

The first requirement for learning object-oriented design is to immerse yourself in objects; once you acquire an object-oriented perspective the rest follows naturally.

Software gets build for a reason.

Design Principles

• SOLID (Single responsibility, Open-Closed, Liskov substitution, Interface segregation, Dependency inversion)
• DRY (Don't Repeat Yourself)
• Law of Demeter (LoD)
• Design Patterns

2. Designing Classes with a Single Responsibility

The foundation of an object-oriented system is the message, but the most visible organizational structure is the class.

The goal is to model the application, using classes, such it does what is supposed to do right now and is also easy to change later.

### Deciding what belongs in a class The problem us to know how to write the code but not knowing where to put it.

Organize the code to allow easy of changes

Definition of easy to change

• Changes have no unexpected side effects
• Small changes in requirements require correspondingly small changes in code.
• Existing code is easy to reuse
• The easiest way yo make a change is to add code that in itself is easy to change.

#### The Code should have the following qualities

• Transparent The consequences of change should be obvious in the code that is changing and in distant code relies upon it.
• Reasonable The cost of any change should be proportional to the benefits the change achieves.
• Usable Existing code should be usable in new and unexpected contexts.
• Exemplary The code itself should encourage those who change it to perpetuate these qualities.

Code that is Transparent Reasonable Usable and Exemplary (TRUE) meets today's needs but can also be changed to meet the needs of the future.

The first step in creating code that is TRUE is to ensure that each class has a single, well-defined responsibility.

Create Classes That Have a Single Responsibility

A class should do the smallest possible useful thing.

Why Single Responsibility Matters

Applications that are easy to change consist of classes that are easy to reuse. Reusable classes are pluggable units of well-defined behavior that have few entanglements. 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.

Determine if a class has a single responsibility

Pretend that the class is sentient and to interrogate it, rephrase everyone of its methods as a question, if the question seems perfectly reasonable you are on solid ground.

Another way is to know if a class has a single responsibility is trying to describe it in one sentence. A class should do the smallest possible useful thing, that thing ought to be simple to describe. If you use the word "and" the class likely has more than one responsibility, if you use the word "or" the class has more than one responsibility and they aren't very related (this is knopn as Cohesion).

Single Responsibility Principle

"A class has responsibilities that fulfill its purpose"

SRP does'n require that a class do only one very narrow thing or that it change for only a single nitpicky reason.

SRP requires a class be cohesive, that everything the class does be highly related to its purpose.

---

• 3. Managing Dependencies
• 4. Creating Flexible Interfaces
• 5. Reducing Costs with Duck Typing
• 6. Acquiring Behavior Through Inheritance
• 7. Sharing Role Behavior with Modules
• 8. Combining Objects with Composition
• 9. Designing Cost-Effective Tests