In Software Engineering, a design pattern is a repeatable solution to a common problem occuring in software design. It is more of as description or template for how to solve the problem that can be used in different situations.
Design Pattern
- Set of guidelines
- Provided solutions for common software design problems
- Consists of one or several software design elements such as modules, interfaces, classes, objects, methods, functions, processes, threads, etc.,
- Relationships among the elements, and a behavioral description
Advantages:
- Improve the structure of software
- Simplify maintenance
- Shared language for communicating
- Separation of concerns
- Minimize logic needed in views
- Enhance testability
- Reduce development time
- Easy to customize applications
Disadvantages:
- Design pattern can be overkill in Simple UI
The Gang of Four (GoF) patterns are generally considered the foundation for all other patterns. They are categorized in three groups: Creational, Structural, and Behavioral.
GOF: ??: The authors of the DesignPatternsBook came to be known as the "Gang of Four." The name of the book ("Design Patterns: Elements of Reusable Object-Oriented Software") is too long for e-mail, so "book by the gang of four" became a shorthand name for it. After all, it isn't the ONLY book on patterns. That got shortened to "GOF book", which is pretty cryptic the first time you hear it.
- Erich Gamma
- Richard Helm
- Ralph Johnson
- John Vlissides
DESIGN PATTERN CLASSIFICATIONS
- Creational patterns
- Structural patterns
- Behavioral patterns
| Creational Patterns | |
| Abstract Factory | Creates an instance of several families of classes |
| Builder | Separates object construction from its representation |
| Factory Method | Creates an instance of several derived classes |
| Prototype | A fully initialized instance to be copied or cloned |
| Singleton | A class of which only a single instance can exist |
| Structural Patterns | |
| Adapter | Match interfaces of different classes |
| Bridge | Separates an object’s interface from its implementation |
| Composite | A tree structure of simple and composite objects |
| Decorator | Add responsibilities to objects dynamically |
| Facade | A single class that represents an entire subsystem |
| Flyweight | A fine-grained instance used for efficient sharing |
| Proxy | An object representing another object |
| Behavioral Patterns | |
| Chain of Resp. | A way of passing a request between a chain of objects |
| Command | Encapsulate a command request as an object |
| Interpreter | A way to include language elements in a program |
| Iterator | Sequentially access the elements of a collection |
| Mediator | Defines simplified communication between classes |
| Memento | Capture and restore an object's internal state |
| Observer | A way of notifying change to a number of classes |
| State | Alter an object's behavior when its state changes |
| Strategy | Encapsulates an algorithm inside a class |
| Template Method | Defer the exact steps of an algorithm to a subclass |
| Visitor | Defines a new operation to a class without change |
More patterns
In software engineering, concurrency patterns are those types of design patterns that deal with multi-threaded programming paradigm. Examples of this class of patterns include:
Enterprise Application Integration (EAI) is defined as the use of software and computer systems architectural principles to integrate a set of enterprise computer applications. EAI is the discipline of integrating applications and data within the enterprise into automated business processes.
The Pattern Reference Model will describe as
- Business problem.
Ex: What is the business trying to do? In this we define the scope of the problem by decomposing the business topic into logical business areas from which the requirements for business services can be defined. This allows us to identify the business services needed to solve the business problem.
- Conceptual solution.
Ex: What is the shape of the IT solution? From these services, the first sets of IT services can be deduced and defined in a conceptual solution, and their business service levels can be described in the requirements.
- Logical solution.
Ex: What IT services do we need to realize the solution? In this we refine the IT services into more granular logical components, and mechanisms that are required to create the logical solution. In doing this we evaluate alternative ways of expressing the solution and choose the one we will take forward to implement.
- Physical solution.
Ex: With what infrastructural services will the solution be created? Now the logical solution is fully converted into a hardware and software topological diagram, with products and connections defined. This does not take much account of non-functional business requirements at this time, because it is a generic pattern. However it may identify variations (different options) that would be driven by a loose description of non-functional requirements (such as "very scaleable, very resilient" versus "small, inexpensive").
- Implementation solution.
Ex: How should the Microsoft technology be implemented in the solution? Finally we show more detail about how the Microsoft technology should be implemented in the particular physical configuration.
