Design Patterns

« Previous Next »

What is design pattern?

• Design pattern is a general reusable solution to a commonly occurring problem in software design.
• Design patterns are the best practices and solutions to solve software development problems.
• Design patterns were obtained by experience (trial and error) by numerous software developers over quite a substantial period of time.
• Design pattern is not in source code format, it is description or template for how to solve any software problem that can be used in different situations.
• Design patterns are programming language independent concepts like OOPS Concepts.
• Object-oriented design patterns typically show relationships and interactions between classes or objects.

What are the different types of design patterns?

• Creational patterns
• Structural patterns
• Behavioral patterns

Creational Patterns

Creational Patterns are ones that create objects, rather than having you instantiate objects directly. These patterns are useful in developing program more flexibility in deciding which objects need to be created for a particular scenario or case.

• Abstract factory: provides an interface for creating families of related or dependent objects without specifying their concrete classes.
• Factory method: defines an interface for creating a single object, but sub classes should decide which class to instantiate. Factory Method lets a class defer instantiation to sub classes.
• Singleton pattern: restricts object creation for a class to only one instance.
  Two types to create singleton design pattern.
  • Early Instantiation: creating instance at initial time.
  • Lazy Instantiation: creating instance when required later.
• Builder pattern: creates complex objects by separating construction and representation.
• Prototype pattern: creates objects by cloning an existing object.
• Object Pool Pattern: provides to reuse the object that are expensive to create.

Structural patterns

These patterns related to class and object composition. Mostly uses inheritance to compose interfaces and define paths to compose objects to get new functionality.

• Adapter pattern: provides classes with incompatible interfaces, to work together by wrapping its own interface around that of an already existing class. Creating new class by extending existing class and incompatible interfaces.
• Bridge pattern: decouples an abstraction from its implementation so that the two can vary independently.
• Composite pattern: composes zero-or-more similar objects so that they can be manipulated as one object.
• Decorator pattern: dynamically adds/overrides behaviour in an existing method of an object.
• Facade pattern: provides a simplified interface to a large body of code.
• Flyweight pattern: reduces the cost of creating and manipulating a large number of similar objects.
• Proxy pattern: provides a placeholder for another object to control access, reduce cost, and reduce complexity.

Behavioral patterns

These design patterns are related to communication between objects.

• Chain of responsibility pattern: delegates commands to a chain of processing objects.
• Command pattern: creates objects which encapsulate actions and parameters.
• Interpreter pattern: implements a specialized language.
• Iterator pattern: accesses the elements of an object sequentially without exposing its underlying representation.
• Mediator pattern: provides loose coupling between classes by being the only class that has detailed knowledge of their methods.
• Memento pattern: provides the ability to restore an object to its previous state.
• Observer pattern: publish/subscribe pattern which allows a number of observer objects to see an event.
• State pattern: provides an object to update its behavior when its internal state changes.
• Strategy pattern: provides one of a family of algorithms to be selected on-the-fly at runtime.
• Template method pattern: defines the skeleton of an algorithm as an abstract class, allowing its subclasses to provide concrete behavior.
• Visitor pattern: separates an algorithm from an object structure by moving the hierarchy of methods into one object.

« Previous Next »