Let’s start Cheat Sheet on Object Oriented Rules.

Single Respon­­si­b­ility Principle A class changes for only one reason
Op­en/­­Closed Principle A class should be open for extension, closed for editing
Li­skov’s Substi­­tution Principle Derived types should cleanly and easily replace base types
In­terface Segreg­­ation Principle Favor multiple single­­-p­u­rpose interfaces over composite
De­pen­­dency Inversion Principle Concrete classes depend on abstra­­ct­ions, not vice-versa

SOLID principles

Common Refact­­orings
Encaps­­ulate Field
Generalize Type
Type-C­­he­cking ⇒ State/­­St­r­ategy
Condit­­ional ⇒ Polymo­­rphism
Extract Method
Extract Class
Move/R­­ename Method or Field
Move to Superc­­la­s­s­/S­­ubclass

More Refact­­orings

Basic OO Terms
Abstra­­ction The process of separating ideas from specific instances of those ideas at work.
Polymo­­rphism The provision of a single interface to entities of different types. Subtyping.
Inheri­­tance When an object or class is based on another object or class, using the same implem­­en­t­a­tion; it is a mechanism for code reuse. The relati­­on­ships of objects or classes through inheri­­tance give rise to a hierarchy.
Encaps­­ul­ation Enclosing objects in a common interface in a way that makes them interc­­ha­n­g­eable, and guards their states from invalid changes.
Other Principles
DRY – Don’t repeat yourself Duplic­­ation should be abstracted
Hollywood Principle “­­Don’t call us, we’ll call you”
YAGNI – You Ain’t Gonna Need It Only code what you need now
KISS – Keep it simple, stupid! Favor clarity over cleverness
Law of Demeter Only talk to related classes
Convention Over Config­­ur­ation Defaults cover 90% of uses
Encaps­­ul­ation What happens in Vegas…
Design By Contract And then write tests
Low Coupling Minimize the depend­encies
Common Closure Principle Classes that change together, stay together
Avoid Premature Optimi­zation Don’t even think about optimi­zation unless your code is working
Separation of Concerns Different functi­ona­lities are distinctly managed
Embrace Change Expect and welcome any changes
Basic Principles
Encaps­­ulate what varies
Code to an interface rather than to an implem­­en­t­ation
Each class in your applic­­ation should have only one reason to change
Classes are about behavior and functi­­on­a­lity
Design Patterns
Abstract Factory Creational
Builder Creational
Factory Method Creational
Prototype Creational
Singleton Creational
Adapter Structural
Bridge Structural
Composite Structural
Decorator Structural
Facade Structural
Flyweight Structural
Proxy Structural
Chain of Respon­­si­b­ility Behavioral
Command Behavioral
Interp­­reter Behavioral
Iterator Behavioral
Mediator Behavioral
Memento Behavioral
Observer Behavioral
State Behavioral
Strategy Behavioral
Template Method Behavioral
Visitor Behavioral
Favor the following over inheri­­tance
Delegation When you hand over the respon­­si­b­ility for a particular task to another class or method.
Compos­­ition Use behavior from a family of other classes, and change that behavior at runtime.
Aggreg­­ation When one class is used as part of another class, but still exists outside of that other class.
Access Modifiers
Private Only inside the same class instance
Protected Inside same or derived class instances
Public All other classes linkin­­g/­r­e­fe­­rencing the class
Internal Only other classes in the same assembly
Protected Internal All classes in same assembly, or derived classes in other assembly
Static Accessible on the class itself (can combine with other accessors)

Leave a Comment