Design Patterns Overview

Design Pattern defined:

A Pattern is a solution to a problem in a context.

The context is the situation in which the pattern applies. This should be a recurring situation.

The problem refers to the goal you are trying to achieve in this context, but it also refers to any constraints that occur in the context.

The solution is what you're after: a general design that anyone can apply which resolves the goal and set of constraints.

Design Patterns give you a shared vocabulary with other developers. It also elevates your thinking about architectures by letting you think at the pattern level , not the nitty gritty object level.

OO Basics:

• Abstraction
• Encapsulation
• Polymorphism
• Inheritance

OO Principles:

• Encapsulate what varies.

        Identify the aspects of your application that vary and separate them from what stays the same.

• Program to an interface, not an implementation.
• Favor composition over inheritance.
• Strive for loosely coupled designs between objects that interact.
• The Open-Closed Principle - Class should be open for extension, but closed for modification.
• The Dependency Inversion Principle - Depend upon abstractions. Do not depend upon concrete classes.
• Principle of Least Knowledge - talk only to our immediate friends.
• The Hollywood Principle - Don't call us, we'll call you.
• Single Responsibility - A class should have only one reason to change.

Design Patterns:

• Strategy Pattern: 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 Pattern: The Observer Pattern defines a one-to-many dependency between objects so that when one object changes state, all of its dependents are notified and updated automatically.
• Decorator Pattern: The Decorator Pattern attaches additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.
• Factory Method Pattern: 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 subclass.
• Abstract Factory Pattern: The Abstract Factory Pattern provides an interface for creating families of related or dependent objects without specifying their concrete classes.
• Singleton Pattern: The Singleton Pattern ensures a class has only one instance, and provides a global point of access to it.
• Command Pattern: 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 Pattern: 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 Pattern: 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 Pattern: 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. (Hook)
• Iterator Pattern: The Iterator Pattern provides a way to access the elements of an aggregate object sequentially without exposing its underlying representation.
• Composite Pattern: The Composite Pattern allows you to compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.
• State Pattern: The State Pattern allows an object to alter its behavior when its internal state changes. The object will appear to change its class.
• Proxy Pattern: The Proxy Pattern provides a surrogate or placeholder for another object to control access to it.
• Compound Patterns: A Compound Pattern combines two or more patterns into a solution that solves a recurring or general problem. (MVC)

Thinking in Patterns:

• Keep it simple
• Design Patterns aren't a magic bullet; in fact they're not even a bullet!
• Refactoring time is Patterns time!
• Take out what you don't really need. Don't be afraid to remove a Design Pattern from your design.
• If you don't need it now, don't do it now.
• Don't forget the power of the shared vocabulary.