Subscribe to Sergio Tapia - Lost in the GC.        RSS Feed

The OO Cheat Sheet - The Motherload

Icon 5 Comments
Full credit and source goes to Mmiika.

During my usual morning stroll on some programming forums, someone shared this fantastic link:

It's a compilation of good articles encompassing a wide variety of different OO rules and paradigms. Check it out. :)

S.O.L.I.D. Class Design Principles

Single Responsibility Principle (SRP)
A class should have only one reason to change. For example, if a change to the business rules causes a class to change, then a change to the database schema, GUI, report format, or any other segment of the system should not force that class to change.


Open/Closed Principle (OCP)
Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

Liskov Substitution Principle (LSP)
Subtypes must be substitutable for their base types. If class A inherits from class B, then wherever you can use A you should be able to use B. E.g. remember that square is not necessarily a rectangle!

When extending: Preconditions cannot be straightened, Postconditions cannot be loosened, visible Invariants cannot be changed (?).

Invariants: users depend on this both before and after sending a message. Use a proper set-based inheritance relationship. Not following set semantics is very risky.

Subsumption Rule: A reference to a subtype can be used in any context where a reference to a super type is expected. This principle extremely limits what SHOULD be done with the pure extension (inheritance) mechanism. Do not follow at your own risk.

Interface Segregation Principle (ISP)
The dependency of one class to another one should depend on the smallest possible interface.

Dependency Inversion Principle (DIP)
Depend upon abstractions (interfaces), not upon concrete classes.

Other Important Ones
Law of Demeter
aka Principle of Least Knowledge: Only talk to your friends
Any method M of an object O may only invoke the methods of the following kinds of objects:

  • itself
  • its arguments/parameters
  • any objects it creates/instantiates
  • its direct component objects


Hollywood Principle
Don’t call us, we’ll call you.

Don’t Repeat Yourself (DRY)

Remove duplication.

Program to an interface, not an implementation
Just another way to say dependency injection, or IoC.

You Ain’t Gonna Need It (YAGNI)
Do not add code that you “think will be used later”. Add code only at “Last Responsible Moment”

Keep It Simple, Stupid (KISS)
What is the simplest thing that could possibly work?

Encapsulation and Information Hiding

http://en.wikipedia....mputer_science) http://en.wikipedia....ormation_hiding
Separation of Concerns (SoC)

High Cohesion

Low/Loose coupling

Head First Design patterns page 53

Convention over Configuration (CoC)

Command-query separation (CQS)


[edit] Design by Contract (DbC)


Dependency Injection (DI)
Inversion of Control (IoC)
Avoid Fragile Baseclass

Has-a Is-a http://en.wikipedia....ect_composition
What is Identity


Option-operand separation

Intention Revealing Names

Zero Friction Development
Encapsulate Variation

Separate what varies from what stays the same. Also known as Serenity Principle.
Head First Design patterns page 9, 111

Composition over inheritance

Head First Design patterns page 23, 243, 397

Common Closure Principle

Classes that change together must be placed in the same package.

5 Comments On This Entry

Page 1 of 1


19 April 2011 - 11:05 AM
WOW. Nice composite of links and resources.


19 April 2011 - 11:56 AM
Very nice.

Sergio Tapia 

19 April 2011 - 01:09 PM
I'm glad you guys liked it. Don't forget to share this link to some of your programming buddies. :D


19 April 2011 - 02:07 PM
Actually, a square is always a rectangle. Maybe you meant it the other away around. :P

Sergio Tapia 

19 April 2011 - 04:31 PM
Taken from Reddit where I found this. Someone posted your exact same response.

I'm assuming you are aware of the example to which the author is referring, but in case you aren't or in case someone else is curious:

class Rectangle {
  private int _w, _h;

  // Some rectangle stuff goes here: constructors,
  // accessor functions, etc...

  int SetWidth( int w ) { _w = w; }
  int SetHeight( int h ) { _h = h; }

class Square : public Rectangle {
  public Square( int w ) : Rectangle( w, w ) { }

void Foo() {
  Square s(10);
  s.SetHeight(4); // uh oh! Now we have a square that is not square!

The point is that even though mathematically a square is always a rectangle, this does not imply that a Square class has an is-a relationship with a Rectangle class in an OO programming language. This problem arises because Rectangle is mutable; thus, one solution is to make Rectangles (and therefore Squares) immutable.

Another would be to not model the relationship between the Rectangle class and the Square class as an inheritance relationship.
Page 1 of 1

Trackbacks for this entry [ Trackback URL ]

There are no Trackbacks for this entry

0 user(s) viewing

0 Guests
0 member(s)
0 anonymous member(s)

About Me

Posted Image

Bienvenidos! I'm a USA ex-pat living in Bolivia for the past 10 years. Web development is my forte with a heavy lean for usability and optimization. I'm fluent in both English and Spanish. I guest write for the popular Python website Python Central. Visit my website.