Design Patterns
A design pattern in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. Each pattern describes a problem that occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. The usefulness of speaking of patterns is to have a common terminology for discussing the situations designers already see over and over.
There are hundreds of books available and many times that of online articles discussing design patterns. The seminal work in the field is Design Patterns - GoF - Gamma, Helm, Johnson and Vlissides, 1995. It is not my intention here to replicate any of that work, only to show how design patterns can be applied using the SQL language. All of the examples I've seen have been for object oriented languages. Since the late 80's when I was programming in ANSI C my contention has been that you can, and should, use object oriented principles in any language.
Here I will show some examples of the implementation of certain design patterns, an object oriented technique, in the SQL language. I will not attempt to "force fit" SQL into one of the design patterns, rather I will show what seems to make sense to me. In some cases that may be a good match, in other cases it may only be a remote approximation. My goal is not to replicate the design patterns exactly, but to show that the intent of the pattern can be met using the SQL language. Finally, there are many patterns to choose from. I have chosen to stick almost solely to those from Design Patterns - GoF - Gamma, Helm, Johnson and Vlissides, 1995 for my initial effort. That doesn't mean that you can't implement others, only that I chose to limit myself to core functionality. It is possible I may include others as I need them in the development of Chamomile.
I have also created several patterns that I feel are needed to address the requirements of SQL, a set based rather than object oriented or procedure language whose sole purpose is to store, protect, and manipulate data.
Creational
Creational patterns are ones that create objects for you, rather than having you instantiate objects directly. This gives your program more flexibility in deciding which objects need to be created for a given case.
- Abstract Factory groups object factories that have a common theme.
- Builder constructs complex objects by separating construction and representation.
- Factory Method creates objects without specifying the exact class to create.
- [Prototype](prototype_pattern) creates objects by cloning an existing object. It is used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects. This pattern is used to; avoid subclasses of an object creator in the client application, like the abstract factory pattern does, avoid the inherent cost of creating a new object in the standard way (e.g., using the 'new' keyword) when it is prohibitively expensive for a given application.
- [Singleton](singleton_pattern) restricts object creation for a class to only one instance. The [singleton pattern](http://en.wikipedia.org/wiki/Singleton_pattern) is a design pattern that restricts the instantiation of a class to one object. This is useful when exactly one object is needed to coordinate actions across the system. The concept is sometimes generalized to systems that operate more efficiently when only one object exists, or that restrict the instantiation to a certain number of objects. The term comes from the mathematical concept of a singleton. [In mathematics](http://en.wikipedia.org/wiki/Singleton_(mathematics)), a singleton, also known as a unit set, is a set with exactly one element. For example, the set {0} is a singleton. The term is also used for a 1-tuple (a sequence with one element).
Structural
These concern class and object composition. They use inheritance to compose interfaces and define ways to compose objects to obtain new functionality.
- Adapter allows classes with incompatible interfaces to work together by wrapping its own interface around that of an already existing class.
- [Bridge pattern](bridge_pattern) - Decouples an interface from its implementation so that the two can vary independently. Bridge decouples an abstraction from its implementation so that the two can vary independently.
- Composite composes zero-or-more similar objects so that they can be manipulated as one object.
- Decorator dynamically adds/overrides behaviour in an existing method of an object.
- [Facade](facade_pattern) - Provides a simplified interface to a larger body of code.
- Flyweight reduces the cost of creating and manipulating a large number of similar objects.
- Proxy provides a placeholder for another object to control access, reduce cost, and reduce complexity.
- [Connector](connector_pattern) (Katherine E. Lightsey) - collapses a set of objects and/or interfaces into a lesser number of objects specifically to improve performance.
- [Validator](validator_pattern) (Katherine E. Lightsey) - validates that data conforms to a specification.
- [Vault](vault_pattern) (Katherine E. Lightsey) - protects data from misuse.
Behavioral
Most of these design patterns are specifically concerned with communication between objects.
- [Chain of responsibility pattern](chain_of_command_pattern) - The chain-of-responsibility pattern is a design pattern consisting of a source of command objects and a series of processing objects. Each processing object contains logic that defines the types of command objects that it can handle; the rest are passed to the next processing object in the chain. A mechanism also exists for adding new processing objects to the end of this chain. Chain of responsibility delegates commands to a chain of processing objects.
- [Command pattern](command_pattern) - The command pattern is a behavioral design pattern in which an object is used to represent and encapsulate all the information needed to call a method at a later time. This information includes the method name, the object that owns the method and values for the method parameters. Command creates objects which encapsulate actions and parameters.
- Interpreter implements a specialized language.
- Iterator accesses the elements of an object sequentially without exposing its underlying representation.
- [Mediator](mediator_pattern) - The essence of the Mediator Pattern is to "Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently. Allows loose coupling between classes by being the only class that has detailed knowledge of their methods.
- Memento provides the ability to restore an object to its previous state (undo).
- Observer is a publish/subscribe pattern which allows a number of observer objects to see an event.
- State allows an object to alter its behavior when its internal state changes.
- [Strategy](strategy_pattern) - The strategy pattern (also known as the policy pattern) is a software design pattern, whereby an algorithm's behavior can be selected at run time. Formally speaking, the strategy pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it. Strategy allows one of a family of algorithms to be selected on-the-fly at run time.
- Template method defines the skeleton of an algorithm as an abstract class, allowing its subclasses to provide concrete behavior.
- Visitor separates an algorithm from an object structure by moving the hierarchy of methods into one object.
Anti-Patterns
There must be at least two key elements present to formally distinguish an actual anti-pattern from a simple bad habit, bad practice, or bad idea:
Some repeated pattern of action, process or structure that initially appears to be beneficial, but ultimately produces more bad consequences than beneficial results, and
An alternative solution exists that is clearly documented, proven in actual practice and repeatable.
copyright Katherine Elizabeth Lightsey 1959-2013 (aka; my life)
"Set patterns, incapable of adaptability, of pliability, only offer a better cage. Truth is outside of all patterns." - Bruce Lee, Tao of Jeet Kune Do
Wiki: Home
Wiki: bridge_pattern
Wiki: chain_of_command_pattern
Wiki: command_pattern
Wiki: connector_pattern
Wiki: facade_pattern
Wiki: mediator_pattern
Wiki: prototype_pattern
Wiki: singleton_pattern
Wiki: software_architecture
Wiki: strategy_pattern
Wiki: validator_pattern
Wiki: vault_pattern