Welcome to Shaun Luttin's public notebook. It contains rough, practical notes. The guiding idea is that, despite what marketing tells us, there are no experts at anything. Sharing our half-baked ideas helps everyone. We're all just muddling thru. Find out more about our work at bigfont.ca.

Principles of Object Oriented Design

Tags: design-patterns


Some of the following are self-explanatory. Others require some explanation.

  1. Encapsulate what varies. Restrict outside access to the details of routines that might need to change with changing requirements.
  2. Program to interfaces not implementations.
  3. Prefer composition over inheritance.
  4. Strive for loosely coupled designs among objects that interact.
  5. Only talk to your friends.
  6. Don't call us; we'll call you.
  7. Depend on abstractions not on concrete classes.
  8. Keep classes open to extension and closed to modification.
  9. A class should have only one reason to change.

Those fit into SOLID principles:

  • Single Responsibility
  • Open-closed
  • Liskov Substitution
  • Interface Segregation
  • Dependency Inversion

Then there are the

  • Law of Demeter. This is known as the Principle of Least Knowledge and is often stated as only talk to your friends. For instance, if your friend Suzie introduces you to John, do not ask John to do something for you. Instead, make friends with John before asking him any favours. s.j.DoSomething() breaks the law; j.DoSomething() follows the it. When we call DoSomething() directly thru John, our client code touches fewer components, and by passing thru fewer components, our client code has less if not the least knowledge of the system.
  • Design by Contract
  • Don't Repeat Yourself

See also

  • http://www.slideshare.net/intellizhang/the-oo-design-principles