In software development, a design Pattern describes a general solution to a design problem that recurs repeatedly in many projects. Software designers adapt the Pattern solution to their specific project. Patterns use a formal approach to describing a design problem, its proposed solution, and any other factors that might affect the problem or the solution. A successful Pattern should have established itself as leading to a good solution in three previous projects or situations.
Here are 3 categories of the Patterns involved in software designing...
1) Creational Patterns
Abstract factory pattern: centralize decision of what factory to instantiate
Factory method pattern: centralize creation of an object of a specific type choosing one of several implementations
Anonymous subroutine objects pattern
Builder pattern: separate the construction of a complex object from its representation
Lazy initialization pattern: tactic of delaying the creation of an object, the calculation of a value, or some other expensive process until the needed first time
Prototype pattern: used when the inherent cost of creating a new object in the standard way (e.g., using the 'new' keyword) is prohibitively expensive
Singleton pattern: restrict instantiation of a class to one object
2) Structural Patterns
Adapter pattern: 'adapts' one interface for a class into one that a client expects
Composite pattern: a tree structure of objects where every object has the same interface
Aggregate pattern: a version of the Composite pattern with methods for aggregation of children
Bridge pattern: decouple an abstraction from its implementation so that the two can vary independently
Container pattern: create objects for the sole purpose of holding other objects and managing them
Decorator pattern: add additional functionality to a class at run time where subclassing would result in an exponential rise of new classes
Extensibility pattern: aka. Framework - hide complex code behind a simple interface
Facade pattern: create a simplified interface of an existing interface to ease usage for common tasks
Flyweight pattern: a high quantity of objects share a common properties object to save space
Proxy pattern: a class functioning as an interface to another thing
Pipes and filters: a chain of processes where the output of each process is the input of the next
Private class data pattern: restrict accessor/mutator access
3) Behavioral Patterns
Chain of responsibility pattern: Command objects are handled or passed on to other objects by logic-containing processing objects
Command pattern: Command objects encapsulate an action and its parameters
Interpreter pattern: Implement a specialized computer language to rapidly solve a specific set of problems
Iterator pattern: Iterators are used to access the elements of an aggregate object sequentially without exposing its underlying representation
Mediator pattern: Provides a unified interface to a set of interfaces in a subsystem
Memento pattern: Provides the ability to restore an object to its previous state (rollback)
Observer pattern: aka Publish/Subscribe or Event Listener. Objects register to observe an event which may be raised by another object
State pattern: A clean way for an object to partially change its type at run time
Strategy pattern: Algorithms can be selected on the fly
Template method pattern: Describes the program skeleton of a program
Visitor pattern: A way to separate an algorithm from an object
Single-serving visitor pattern: Optimise the implementation of a visitor that is allocated, used only once, and then deleted
Hierarchical visitor pattern: Provide a way to visit every node in a hierarchical data structure such as a tree
Look for subsequent posts for clarification of each one from C# point of view...
Cheers!!!