According to Gang of Four(GOF) any software is classified in to one of the three categories.
I read so many books about design patterns which provide a lot of information about Design Patterns in a language neutral way or related to a particular programming language. I am trying to complement the great books by providing the precise and concise information that is required in the day to day programming of a Java Developer.
Any software can be classified into one of the three categories -Framework, Toolkit, Application.
I read so many books about design patterns which provide a lot of information about Design Patterns in a language neutral way or related to a particular programming language. I am trying to complement the great books by providing the precise and concise information that is required in the day to day programming of a Java Developer.
Any software can be classified into one of the three categories -Framework, Toolkit, Application.
Framework - Framework defines a set of steps to create an application. Framework provides design reuse.
Toolkit - Toolkit provides some utility functions to an existing application. Toolkit provides code reuse.
Application - Application is some thing that is specific to the project, and is not useful outside the context of the current application.
Gang of Four divided the Design Patterns in to 3 types based on their usage.
There are 3 types of Gang of Four Design patterns.
There are 3 types of Gang of Four Design patterns.
We will go in to the details of the each of the design patterns with an example e-commerce application using Java.
Each design pattern is explained with description, implementation code, design, and use case.
Two common characteristic of using Design patterns in the code are
The use of composition over inheritance, as composition gives the ability to change the class behavior at runtime, where as inheritance lets us to extend the class behavior at compile time only.
Also most often more classes are required to use design patters, it may look daunting effort, but this is negligible compared to the benefits the design patterns provide in the long run.
1.Creational Patterns
1.1 Abstract Factory
Description
Abstract Factory provides an interface for creating families of related or dependent objects without specifying their concrete classes.
Implementation
Class Diagram
Sequence Diagram
Sample Code
1.2 Builder
Description
Separate the construction of an object from its representation so that the same construction process can create different representations of the object.
Implementation
Class Diagram
Sequence Diagram
Sample Code
Use cases
1.3 Factory Method
Description
Define an interface for creating an object, but let subclasses decide which classes to instantiate. Factory method lets a class defer instantiation to subclasses.
Implementation
Class Diagram
Sequence Diagram
Sample Code
Sample Code
Use cases
1.4 Prototype
Description
Specify the kind of objects to create using a prototypical instance, and create new objects by copying this prototype.
Implementation
Class Diagram
Sequence Diagram
Sample Code
Sample Code
Use cases
1.5 Singleton
Description
Ensure a class only has only one instance, and provide a global point of access to it.
Implementation
Class Diagram
Sequence Diagram
Sample Code
Sample Code
Use cases
Singleton makes sure that there is only instance of the class is created per the Class loader.
2. Structural Patterns
2.1 Adapter
Description
Convert the interface of a class into another interface that the clients expect.
Implementation
Class Diagram
Sequence Diagram
Sample Code
Use cases
2.2 Bridge
Description
Decouple an abstraction from its implementation so that the two can vary independently.
Implementation
Class Diagram
Sequence Diagram
Sample Code
Sample Code
Use cases
2.3 Composite
Description
Compose objects into tree structures to represent whole-part hierarchies.
Implementation
Class Diagram
Sequence Diagram
Sample Code
Sample Code
Use cases
2.4 Decorator
Description
Attach additional responsibilities to an object dynamically.
Implementation
Use cases
2.5 Facade
Description
Provides a unified interface to a set of interfaces in a sub system.
Implementation
Class Diagram
Sequence Diagram
Sample Code
Use cases
2.6 Flyweight
Description
Use sharing to support large number of fine grained objects efficiently.
Implementation
Class Diagram
Sequence Diagram
Sample Code
Sample Code
Use cases
2.7 Proxy
Description
Provides a surrogate or placeholder for another object to control access to it.
Implementation
Class Diagram
Sequence Diagram
Sample Code
Sample Code
Use cases
3. Behavioral Patterns
3.1 Chain of Responsibility
Description
Avoid coupling of sender of a request to its recover by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it.
Implementation
Class Diagram
Sequence Diagram
Sample Code
Sample Code
Use cases
3.2 Command
Description
Encapsulate a request as an object, there by letting you parameterize clients with different requests, queue or log requests, and support undoable operations.
Implementation
Class Diagram
Sequence Diagram
Sample Code
Sample Code
Use cases
3.3 Interpreter
Description
Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in that language.
Implementation
Class Diagram
Sequence Diagram
Sample Code
Sample Code
Use cases
3.4 Iterator
Description
Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.
Implementation
Class Diagram
Sequence Diagram
Sample Code
Sample Code
Use cases
3.5 Mediator
Description
Define an object that encapsulates how a set of objects interact. Metiator promotes loose coupling by keeping objects from referring to each other explicitly, and lets you vary their interactions independently.
Implementation
Class Diagram
Sequence Diagram
Sample Code
Sample Code
Use cases
3.6 Memento
Description
Without violating encapsulation, capture and externalize an object's internal state so that the object can be restored to this state later.
Implementation
Use cases
3.7 Observer
Description
Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and update automatically.
Implementation
Class Diagram
Sequence Diagram
Sample Code
Sample Code
Use cases
3.8 State
Description
Allow an object to alter its behavior when its internal state changes. The object will appear to change its class.
Implementation
Class Diagram
Sequence Diagram
Sample Code
Sample Code
Use cases
3.9 Strategy
Description
Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.
Implementation
Class Diagram
Sequence Diagram
Sample Code
Use cases
3.10 Template Method
Description
Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets sub classes redefine certain steps of an algorithm without changing the algorithm's structure.
Implementation
Class Diagram
Sequence Diagram
Sample Code
Use cases
3.11 Visitor
Description
Represent an operation to be performed on the elements of an object structure. Visitors lets you define a new operation without changing the classes of the elements on which it operates.
Comments
Post a Comment