Design Patterns
Basic Design Patterns (23) in Software Development:
Design Patterns are recurring solutions to design problems encountred in software development.
In elobarating further design patterns are like blue prints or already modeled solutions which may fit into a problem and provide a better solution. but it should be noted the implementation will vary depending on the problem scenario and context.
Rules of Design Patterns:
Design Patterns are recurring solutions to design problems encountred in software development.
In elobarating further design patterns are like blue prints or already modeled solutions which may fit into a problem and provide a better solution. but it should be noted the implementation will vary depending on the problem scenario and context.
1. Creational Patterns (5) - Creates objects for you
2. Structural Patterns (7) - Puts together Larger structures
3. Behavioural Patterns (11) - Help control communication and flow between objects
There are certain suggestions that need to be adopted when using design patterns
- Program to an interface and not to an implementation
- Favor object composition over inheritance
1. Creational Patterns -
Factory - Provides a simple decsion making class that returns one of several possible
subclasses of an abstract base class depending on the data that are provided
subclasses of an abstract base class depending on the data that are provided
Abstract Factory - provides an interface to create and return one of several families of
related objects
related objects
Builder - seperates the construction of a complex object from its representation, so that several different representations can be created depending on the needs of the
program
program
Prototype - starts with an initialized and instantiated class and copies or clones it to make new instances rather than creating new
Singleton - To create a single instance of a class
2. Structural Patterns
Adapter
Bridge
Composite
Decorator
Facade
Flyweight
Proxy
3. Behavioral Patterns
Command
Strategy
Observer
State
Chain of Responsibility
Interpreter
Iterator
Mediator
Template Method
Visitor
- Client should always call the abstraction (interface) and not the exact implementation
- Future changes should not impact the existing system
- Change always what is changing
- Have loose coupling
Composition
Aggregation
Association
Dependency
Realization (Least couple)
(http://www.go4expert.com/forums/showthread.php?t=5127)
Comments
Post a Comment