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) |
|
Help Us Go Positive!
We offset our carbon usage with Ecologi. Click the link below to help us!
Created By
Metadata
Favourited By
Comments
No comments yet. Add yours below!
Add a Comment
Related Cheat Sheets