Design Patterns Series 18 - More Design Patterns
This Post will discover more than one design pattern. They are all good patterns, but some are not used these days. And some are just plain hard to implement, like the Interpreter Pattern.
Abstract Factory Pattern :
The Abstract Factory Pattern describes a factory of factories, or, more properly thought of, an abstract specification for an actual object factory. Here's the problem: sometimes you might need more than one factory to create objects of a similar nature.
An Abstract Factory is usually implemented as an abstract class that real, concrete factories extend. That unifies what the concrete factories do, while allowing leeway to fit differing requirements.
The Abstract Factory Pattern should "provide an interface for creating families of related or dependent objects without specifying their concrete classes."
Prototype Pattern :
The Prototype Pattern says that when it takes a lot of resources, or a lot of code, to create an object, you should consider simply copying an existing object and customizing it instead.
In code, all you have to do is set up a prototypical object and keep calling the Clone method on it - no need to create your object from scratch in your code every time - and then add some customization to the new object as needed.
The Prototype Pattern should "Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype."
Bridge Pattern :
The inspiration here is that when you have an abstraction that can vary, and that's tied to an implementation that can also vary, you should decouple the two.
The Bridge Pattern should "Decouple an abstraction from its implementation so that the two can vary independently ." Interpreter Pattern :
This is heavy-duty pattern. It is all about putting together your own programming language, or handling an existing one, by creating an interpreter for that language.
To use this pattern, you have to know a fair bit about formal grammars to put together a language. As you can imagine, this is one of those patterns that doesn't see a lot of everyday use because creating your own language is not something many people do.
The Interpreter Pattern should "Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language."
Momento Pattern :
Here is the problem. The client code has total access to the database, so if someone flubs an operation, the database is in danger.
The Memento Pattern is designed to "Without violating encapsulation, capture and externalize an object's internal state so that the object can be restored to this state later."
More than just a save-state undo command, the idea here is to "capture and externalize an object's internal state" for backup. You might do that with a save-state object accessible from both the client code and the database.
The solution, however violates the database's encapsulation, and the Memento Design Pattern starts off by saying, "without violating encapsulation...". So What do you do? You make the save-state object private to the database.
Visitor Pattern :
With the Visitor Pattern , you can add a new operation to a structure of objects, like a Composite structure, without changing the objects in the structure. A visitor object moves from object to object in the structure, visiting each one and capturing its state. When the visitor has captured all the data it needs from the objects in the structure it's visiting, you can call the methods of the visitor.
The Visitor Pattern should "Represent an operation to be preformed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates."
In practice, you usually use a traverser object of some kind that can move around the object structure whose data you want, feeding data to the Visitor object. The Traverser moves the Visitor object from item to item in the Composite.
Abstract Factory Pattern :
The Abstract Factory Pattern describes a factory of factories, or, more properly thought of, an abstract specification for an actual object factory. Here's the problem: sometimes you might need more than one factory to create objects of a similar nature.
An Abstract Factory is usually implemented as an abstract class that real, concrete factories extend. That unifies what the concrete factories do, while allowing leeway to fit differing requirements.
The Abstract Factory Pattern should "provide an interface for creating families of related or dependent objects without specifying their concrete classes."
Prototype Pattern :
The Prototype Pattern says that when it takes a lot of resources, or a lot of code, to create an object, you should consider simply copying an existing object and customizing it instead.
In code, all you have to do is set up a prototypical object and keep calling the Clone method on it - no need to create your object from scratch in your code every time - and then add some customization to the new object as needed.
The Prototype Pattern should "Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype."
Bridge Pattern :
The inspiration here is that when you have an abstraction that can vary, and that's tied to an implementation that can also vary, you should decouple the two.
The Bridge Pattern should "Decouple an abstraction from its implementation so that the two can vary independently ." Interpreter Pattern :
This is heavy-duty pattern. It is all about putting together your own programming language, or handling an existing one, by creating an interpreter for that language.
To use this pattern, you have to know a fair bit about formal grammars to put together a language. As you can imagine, this is one of those patterns that doesn't see a lot of everyday use because creating your own language is not something many people do.
The Interpreter Pattern should "Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language."
Momento Pattern :
Here is the problem. The client code has total access to the database, so if someone flubs an operation, the database is in danger.
The Memento Pattern is designed to "Without violating encapsulation, capture and externalize an object's internal state so that the object can be restored to this state later."
More than just a save-state undo command, the idea here is to "capture and externalize an object's internal state" for backup. You might do that with a save-state object accessible from both the client code and the database.
The solution, however violates the database's encapsulation, and the Memento Design Pattern starts off by saying, "without violating encapsulation...". So What do you do? You make the save-state object private to the database.
Visitor Pattern :
With the Visitor Pattern , you can add a new operation to a structure of objects, like a Composite structure, without changing the objects in the structure. A visitor object moves from object to object in the structure, visiting each one and capturing its state. When the visitor has captured all the data it needs from the objects in the structure it's visiting, you can call the methods of the visitor.
The Visitor Pattern should "Represent an operation to be preformed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates."
In practice, you usually use a traverser object of some kind that can move around the object structure whose data you want, feeding data to the Visitor object. The Traverser moves the Visitor object from item to item in the Composite.
Comments
Post a Comment