Cheatography
https://cheatography.com
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-purpose interfaces over composite
|
|
Concrete classes depend on abstractions, not vice-versa
|
Common Refactorings
Encapsulate Field |
Generalize Type |
Type-Checking ⇒ State/Strategy |
Conditional ⇒ Polymorphism |
Extract Method |
Extract Class |
Move/Rename Method or Field |
Move to Superclass/Subclass |
Basic OO Terms
|
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.
|
|
|
Other Principles
|
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
|
Basic Principles
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 |
|
|
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 inheritance
|
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.
|
Access Modifiers
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) |
|
Created By
Metadata
Favourited By
Comments
No comments yet. Add yours below!
Add a Comment
Related Cheat Sheets