OO Design Principles

OOD.md

Creational design patterns

• Abstract Factory - an instance of several families of classes
• Builder - object construction from its representation
• Factory Method - an instance of several derived classes
• Object Pool - expensive acquisition and release of resources by recycling objects that are no longer in use
• Prototype - fully initialized instance to be copied or cloned
• Singleton - class of which only a single instance can exist

Structural design patterns

• Adapter - interfaces of different classes
• Bridge - an object's interface from its implementation
• Composite - tree structure of simple and composite objects
• Decorator - responsibilities to objects dynamically
• Facade - single class that represents an entire subsystem
• Flyweight - A fine-grained instance used for efficient sharing
• Private Class Data - accessor/mutator access
• Proxy - object representing another object

Behavioral design patterns

• Chain of responsibility - way of passing a request between a chain of objects
• Command - a command request as an object
• Interpreter - way to include language elements in a program
• Iterator - access the elements of a collection
• Mediator - simplified communication between classes
• Memento - and restore an object's internal state
• Null Object - Designed to act as a default value of an object
• Observer - way of notifying change to a number of classes
• State - an object's behavior when its state changes
• Strategy - an algorithm inside a class
• Template method - the exact steps of an algorithm to a subclass
• Visitor - Defines a new operation to a class without change

SOLID

1. Single responsibility principle

   A class should only have a single responsibility, that is, only changes to one part of the software's specification should be able to affect the specification of the class.

2. Open–closed principle

   Software entities ... should be open for extension, but closed for modification.

3. Liskov substitution principle

   Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.;

4. Interface segregation principle

   Many client-specific interfaces are better than one general-purpose interface.

5. Dependency inversion principle

   One should depend upon abstractions, [not] concretions.

GRASP - General Responsibility Assignment Software Patterns

1. Information Expert

   Class should be expert in information from his area of responsibility, but not in others

2. Creator

   Class B that contains class A has to instantiate it

3. Controller

   Similar to Command design pattern

4. Low Coupling

   Coupling is a measure of how strongly one element is connected to, has knowledge of, or relies on other elements.

5. High Cohesion

   High cohesion means that the responsibilities of a given element are strongly related and highly focused

6. Indirection

   Encapsulate interaction among multiple classes into another class

7. Polymorphism

   Use interfaces, not concrete classes

8. Pure Fabrication

   Sometimes you need to create classes that do not exist in your application domain, but nevertheless are useful for design and readability(artificial classes)

9. Protected Variations

   Implement interfaces, so that when you need to change code, you change implementation, not an interface