Chapter 1 - Principles of OOP

Flexibility (The only certainty in life is change!)
Dependency Management
Cost of development
- Avoiding design that anticipates future feature requirements

What is design?
- Ideas about how code should be arranged. Often with the goal to minimize the cost of change later.

S.O.L.I.D.
- Single Responsibility: Code should be responsible for doing one thing and doing it well
- Open/Closed: Entities should be open for extension but closed for modification
- Liskov Subsititution: A child class should be able to replace its parent class in an implementation without disrupting the program.
- Interface Segregation: No client should be forced to depend on methods they don't use. Clients should only know about the methods that interest them.
- Dependency Inversion: Depend on abstractions instead of specific modules. Abstractions should not depend on details, details should depend on abstractions.
D.R.Y.
- Don't Repeat Yourself!
Law of Demeter
- Promote loose coupling though:
  - Objects should have limit knowledge of each other
  - Objects should talk to their friends, don't talk to strangers!
  - Only talk to your immediate friends
The smells of good design
- One should observe the size of classes
- How chatty classes are
- The depth & breadth of inheritance hierarchies
- Number of methods invoked by a single message being sent

Common solutions to often faced problems
- What are some design patterns we often see used (besides MVC)?

When we separate the act of design from the act of programming. Design requires fast and iterative feedback. This way we can quickly see what works and what does not. It is important to prove our designs with implementations.

When building software, build it in increments, and show progress sooner rather than later.

dsilfen-handy/poodr_1.md