Show Menu

Object Oriented Rules Cheat Sheet by

A compilation of two Object Oriented Programming and Design cheat sheets already in the website.
oop     solid

SOLID

A class changes for only one reason
A class should be open for extension, closed for editing
Derived types should cleanly and easily replace base types
Favor multiple single­­-p­u­rpose interfaces over composite
Concrete classes depend on abstra­­ct­ions, not vice-versa

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

Basic OO Terms

Abst­ra­­ction
The process of separating ideas from specific instances of those ideas at work.
Poly­mo­­rph­ism
The provision of a single interface to entities of different types. Subtyping.
Inhe­ri­­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.
Enca­ps­­ula­tion
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
Holl­ywood Princi­ple
"­­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
Conv­ention Over Config­­ur­ation
Defaults cover 90% of uses
Enca­ps­­ula­tion
What happens in Vegas...
Design By Contract
And then write tests
Low Coupling
Minimize the depend­encies
Common Closure Princi­ple
Classes that change together, stay together
Avoid Premature Optimi­zat­ion
Don’t even think about optimi­zation unless your code is working
Sepa­ration 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

Creational
Creational
Creational
Creational
Creational
Structural
Structural
Structural
Structural
Structural
Structural
Structural
Behavioral
Behavioral
Behavioral
Behavioral
Behavioral
Behavioral
Behavioral
Behavioral
Behavioral
Behavioral
Behavioral

Favor the following over inheri­­tance

Dele­gat­ion
When you hand over the respon­­si­b­ility for a particular task to another class or method.
Comp­os­­ition
Use behavior from a family of other classes, and change that behavior at runtime.
Aggr­eg­­ation
When one class is used as part of another class, but still exists outside of that other class.

Access Modifiers

Priv­ate
Only inside the same class instance
Prot­ected
Inside same or derived class instances
Public
All other classes linkin­­g/­r­e­fe­­rencing the class
Inte­rnal
Only other classes in the same assembly
Prot­ected Internal
All classes in same assembly, or derived classes in other assembly
Static
Accessible on the class itself (can combine with other accessors)

Download the Object Oriented Rules Cheat Sheet

2 Pages
//media.cheatography.com/storage/thumb/iamfreee_object-oriented-rules.750.jpg

PDF (recommended)

Alternative Downloads

Share This Cheat Sheet!

 

Comments

No comments yet. Add yours below!

Add a Comment

Your Comment

Please enter your name.

    Please enter your email address

      Please enter your Comment.

          Related Cheat Sheets

          Object Oriented Design Cheat Sheet
          Object-Oriented Design Principles Cheat Sheet
          Java + OOP concept Cheat Sheet