4 Pillars of Object Oriented Programming Cheat Sheet

Another cheat sheet for interviewing.
I think of the 4 pillars consisting of 2 coins. Abstraction / Encapsulation and Inheritance / Polymorphism. So here they are:

• Abstraction – Look at the thing we are modeling: What is it? What are its characteristics? What does it do? Make the object as simple as possible and don't include unnecessary functionality. Data Hiding for simplification.
• Encapsulation – Create a black box around the how. You interact with an object through public properties (setters and getters) and methods. Data Hiding for security.

Both Abstraction and Encapsulation are about all about hiding stuff from us. Protecting us from unnecessary complexity. Abstraction takes place when we fill out our CRC cards when we are designing our classes and Encapsulation takes place when we actually write the code.

• Inheritance – Reuse code! A child class inherits from a parent, from a grandparent, from great grandparent, and so on .. I think of examples of class hierarchies, like Animal, Dog, Pitbull, etc.
• Polymorphism – From "many forms": A child can be substituted for the parent. If you cast a Pitbull as a Dog, you can call the Dog.Bark() method and the Pitbull.Bark() will be run (if it has been overridden). Also, you can have a collection of Dogs, and issue the Bark() command on each of them without caring which kind of Dog is barking (Pitbull or Corgi).

I think of Inheritance and Polymorphism as cause and effect. Because a Pitbull is derived from Dog (Inheritance), the Pitbull can bark like a Dog (Polymorphism).

S.O.L.I.D. Principals Cheat Sheet

I am between gigs, so I have been given opportunities to discus the SOLID Principals along with others of the classics of Object Orientation and basic Computer Science.

The SOLID Principals are somehow connected to Robert C. “Uncle Bob” Martin and his 2000 paper Design Principles and Design Patterns. The word “Solid” appears nowhere in the document. Well anyway, the SOLID Principals are:

• Single Responsibility Principle – A class should do one thing and do it well. No more epic methods or “manager” classed that do everything.
  
• Open/Closed Principle – Open for extension but closed for modification. When you publish an API, others are depending on you. Don’t change the way that a method works. Someone may even be depending on a bug in your code!
• Liskov Substitution Principle – You should be able to substitute a child for a parent and everything work. Named after Barbra Liskov of MIT; learning this kind of detail makes it easier for me to remember.
  
• Interface Segregation Principle – More smaller interfaces! Each interface should do 1 thing. Avoid creating a monster interface that does everything. (this is an extension of the Single Responsibility Principal, right?)
  
• Dependency Inversion – Don’t create an object directly. Use an abstraction to create it. Whether it is the Abstract Factory pattern, an IOC container, simply pass in the object in, or whatever.