Ultimate Object Oriented Rules Cheat Sheet – Master OOP Instantly

In this article, we'll take a look at Show

Let’s start with Ultimate Object Oriented Rules Cheat Sheet for Instant Success.

Single Responsibility Principle	A class changes for only one reason
Open/Closed Principle	A class should be open for extension, closed for editing
Liskov’s Substitution Principle	Derived types should cleanly and easily replace base types
Interface Segregation Principle	Favor multiple single-purpose interfaces over composite
Dependency Inversion Principle	Concrete classes depend on abstractions, not vice-versa

Encapsulate Field

Generalize Type

Type-Checking ⇒ State/Strategy

Conditional ⇒ Polymorphism

Extract Method

Extract Class

Move/Rename Method or Field

Move to Superclass/Subclass

Abstraction	The process of separating ideas from specific instances of those ideas at work.
Polymorphism	The provision of a single interface to entities of different types. Subtyping.
Inheritance	When an object or class is based on another object or class, using the same implementation; it is a mechanism for code reuse. The relationships of objects or classes through inheritance give rise to a hierarchy.
Encapsulation	Enclosing objects in a common interface in a way that makes them interchangeable, and guards their states from invalid changes.

DRY – Don’t repeat yourself	Duplication 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 Configuration	Defaults cover 90% of uses
Encapsulation	What happens in Vegas…
Design By Contract	And then write tests
Low Coupling	Minimize the dependencies
Common Closure Principle	Classes that change together, stay together
Avoid Premature Optimization	Don’t even think about optimization unless your code is working
Separation of Concerns	Different functionalities are distinctly managed
Embrace Change	Expect and welcome any changes

Encapsulate what varies

Code to an interface rather than to an implementation

Each class in your application should have only one reason to change

Classes are about behavior and functionality

Delegation	When you hand over the responsibility for a particular task to another class or method.
Composition	Use behavior from a family of other classes, and change that behavior at runtime.
Aggregation	When one class is used as part of another class, but still exists outside of that other class.

Private	Only inside the same class instance
Protected	Inside same or derived class instances
Public	All other classes linking/referencing 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)