azdanov / design-patterns

Design patterns reference readme.

Design Patterns

A set of common object-oriented ideas that help solve common programming challenges.

Table Of Contents

• Design Patterns
  • Table Of Contents
  • Basics
  • Principles
  • Patterns
    • Strategy
    • Observer
    • Decorator
    • Factory
      • "Simple Factory"
      • Factory Method
      • Abstract Factory
    • Singleton
    • Command
    • Adapter
    • Facade
    • Template Method
    • Iterator
    • Composite
    • State
    • Proxy
    • Compound

Basics

• Abstraction - the quality of dealing with ideas rather than events
• Encapsulation - the action of enclosing something in or as if in a capsule
• Polymorphism - the condition of occurring in several different forms
• Inheritance - the practice of passing on functionality
• Coupling - a term used when two objects are loosely coupled, they can interact, but have very little knowledge of each other.
• Cohesion - a term used as a measure of how closely a class or a module supports a single purpose or responsibility. A module or class has high cohesion when it is designed around a set of related functions, and it has low cohesion when it is designed around a set of unrelated functions.

Principles

• Identify the aspects of your application that vary and separate them from what stays the same.
• Program to an interface, not a concrete implementation.
• Favor composition over inheritance (Composite reuse principle).
• Strive for loosely coupled designs between objects that interact (Loosely Coupled Principle).
• Classes should be open for extension but closed for modification (Open/closed principle).
• Depend on abstractions. Do not depend on concrete classes (Dependency inversion principle).
  • No variable should hold a reference to a concrete class.
  • No class should derive from a concrete class.
  • No method should override an implemented method of any of its base classes.
• Talk only to your immediate friends (Principle of Least Knowledge).
  • Only invoke methods that belong to:
    • The object itself
    • Objects passed in as a parameter to the method
    • Any object the method creates or instantiates
    • Any components of the object
• Don’t call us, we’ll call you (Hollywood Principle).
• A class should have only one reason to change (Single responsibility principle).

Patterns

Strategy

The Strategy Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

---

Observer

The Observer Pattern defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.

---

Decorator

// Example usage of decorator pattern
Beverage beverage = new DarkRoast();
beverage = new Mocha(beverage);
beverage = new Milk(beverage);
System.out.println(beverage.getDescription() + " $" + beverage.cost());
// Output: Dark Roast Coffee, Mocha, Milk $1.29

The Decorator Pattern attaches additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.

---

Factory

"Simple Factory"

"Simple Factory", while not a design pattern, is a simple way to decouple your clients from concrete classes.

Factory Method

The Factory Method Pattern defines an interface for creating an object, but lets subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.

Abstract Factory

The Abstract Factory Pattern provides an interface for creating families of related or dependent objects without specifying their concrete classes.

---

Singleton

The Singleton Pattern ensures a class has only one instance, and provides a global point of access to it.

---

Command

The Command Pattern encapsulates a request as an object, thereby letting you parameterize other objects with different requests, queue or log requests, and support undoable operations.

---

Adapter

The Adapter Pattern converts the interface of a class into another interface the clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces.

---

Facade

The Facade Pattern provides a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.

---

Template Method

The Template Method Pattern defines the skeleton of an algorithm in a method, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm’s structure.

---

Iterator

The Iterator Pattern allows traversal of the elements of an aggregate without exposing the underlying implementation. It also places the task of traversal on the iterator object, not on the aggregate, which simplifies the aggregate interface and implementation, and places the responsibility where it should be.

---

Composite

The Composite Pattern allows us to build structures of objects in the form of trees that contain both compositions of objects and individual objects as nodes. Using a composite structure, we can apply the same operations over both composites and individual objects. In other words, in most cases we can ignore the differences between compositions of objects and individual objects.

---

State

The State Pattern allows an object to alter its behavior when its internal state changes. The object will appear to change its class.

---

Proxy

The Proxy Pattern provides a surrogate or placeholder for another object to control access to it.

---

Compound

A Compound Pattern combines two or more patterns into a solution that solves a recurring or general problem. For example Model-View-Controller.