Design patterns
Design + Pattern = Reusable Working Model
The Software Problem:
• Complexity.
• High Development Costs.
• Software Quantification.
• Software Behavior.
• Software Reuse.
Benefits of Design Patterns:
• Predictability.
• Reduce costs.
• Scalability.
• Reusability.
• Superior software.
Categorizing Design Patterns:
• Creational Patterns.
– Create objects rather than developer instantiate it.
• Structural Patterns.
– Compose group of objects in larger structures.
• Behavioral Patterns.
– Defines communication & flow between objects.
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
CREATIONAL PATTERNS
The creational patterns aim to separate a system from how its objects are created, composed, and represented. They increase the system’s flexibility in terms of the what, who, how, and when of object creation. Creational patterns encapsulate the knowledge about which classes a system uses, but they hide the details of how the instances of these classes are created and put together. Programmers have come to realize that composing systems with inheritance makes those systems too rigid. The creational patterns are designed to break this close coupling. In this and the following chapter, we shall make further use of some C# features that help to abstract the instantiation process—generics and delegates (introduced in Chapters 3 and 4, respectively) are two of these. We’ll start by looking at three small patterns that are helpful in combination with many others. The Prototype pattern ensures that when copies of complex objects are made, they are true copies. The Factory Method pattern is a means of creating objects without knowing the exact subclass being used. Finally, the Singleton pattern ensures that only one of a class can be built and that all users are directed to it.
Creational Patterns:
· Deal with one of the most commonly performed tasks in an OO application, the creation of objects.
· Support a uniform, simple, and controlled mechanism to create objects.
· Allow the encapsulation of the details about what classes are instantiated and how these instances are created.
· Encourage the use of interfaces, which reduces coupling.
Structure Patterns
Our tour of design patterns with the group known as the structural patterns. There are seven patterns that make up the structural group, each with the role of building flexibility, longevity, and security into computer software. The names of the patterns are important, so I’ll introduce them immediately. They are:
• Decorator
• Proxy
• Bridge
• Composite
• Flyweight
• Adapter
• Façade
Structural patterns are concerned with how classes and objects are composed to form larger structures.
Many purposes of the seven structural patterns, here are 10:
• Add new functionality dynamically to existing objects, or remove it (Decorator).
• Control access to an object (Proxy).
• Create expensive objects on demand (Proxy).
• Enable development of the interface and implementation of a component to proceed independently (Bridge).
• Match otherwise incompatible interfaces (Adapter).
• Reduce the cost of working with large numbers of very small objects (Flyweight).
• Reorganize a system with many subsystems into identifiable layers with single entry points (Façade).
• Select or switch implementations at runtime (Bridge).
• Simplify the interface to a complex subsystem (Façade).
• Treat single objects and composite objects in the same way (Composite).
Structural patterns can be employed while a system is being designed, or later on during maintenance and extension. In fact, some of them are specifically useful in the post-production stages of the lifecycle of a software system, when changes are introduced that were not foreseen and when even the interfaces between components need updating. Thus, sometimes when you want to add functionality, you will be working with existing classes that cannot be changed. The Decorator pattern is useful here. Alternatively, you might be able to design a whole system from scratch so that it works in a particularly usable way, with the Composite pattern.
Our exploration of the structural design patterns will span three chapters. In this chapter, we’ll look at the Decorator, Proxy, and Bridge patterns. In Chapter 3, we’ll tackle the Composite and Flyweight patterns, and in Chapter 4, we’ll examine the Adapter and Façade patterns.
Our first three patterns provide ways of adding state and behavior dynamically, controlling the creation and access of objects, and keeping specifications and implementations separate. They do not draw upon any advanced features of C#, relying only on interfaces for structuring; however, at the end of this chapter, I introduce extension methods as an interesting way to implement the Bridge pattern.
Observer - Do various entities need to know about events that have occurred? How to keep dependent object up-to-date.
When we have one to many dependency between objects so when the object changes, its dependents are notified of the update automatically. The best example is something like Excel with data in one cells and we have multiple charts which gets updated when there is change in the data. This design pattern is more useful if we have one sided broadcast communication and is useful when we have one to many relationship.
0 التعليقات:
إرسال تعليق