Cheatography
https://cheatography.com
A compilation of two Object Oriented Programming and Design cheat sheets already in the website.
SOLIDA 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 RefactoringsEncapsulate Field | Generalize Type | Type-Checking ⇒ State/Strategy | Conditional ⇒ Polymorphism | Extract Method | Extract Class | Move/Rename Method or Field | Move to Superclass/Subclass |
Basic OO TermsAbstraction 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 PrinciplesDRY - 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 PrinciplesEncapsulate 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 inheritanceDelegation 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 ModifiersPrivate | 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