Show Menu
Cheatography

Object Oriented Rules Cheat Sheet by [deleted]

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

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

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

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

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)
   
 

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
          OOP key terms and principles Cheat Sheet