Design Patterns
Design patterns are recurring solutions to software design problems you find again and again in real-world application development. Patterns are about design and interaction of objects, as well as providing a communication platform concerning elegant, reusable solutions to commonly encountered programming challenges.
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. Here you will find information on these important patterns.To give you a head start, the C# source code is provided in 2 forms: 'structural' and 'real-world'. Structural code uses type names as defined in the pattern definition and UML diagrams. Real-world code provides real-world programming situations where you may use these patterns.
A third form, '.NET optimized' demonstrates design patterns that exploit built-in .NET 3.5 features, such as, generics, attributes, delegates, object and collection initializers, automatic properties, and reflection. These and much more are available in our Design Pattern Framework 3.5TM. See our Singleton page for a .NET 3.5 Optimized code sample.
Creational Patterns
|
|
Creates an instance of several
families of classes
|
|
Separates object construction
from its representation
|
|
Creates an instance of several
derived classes
|
|
A fully initialized instance to
be copied or cloned
|
|
A class of which only a single
instance can exist
|
Structural Patterns
|
|
Match interfaces of different
classes
|
|
Separates an object’s interface
from its implementation
|
|
A tree structure of simple and
composite objects
|
|
Add responsibilities to objects
dynamically
|
|
A single class that represents
an entire subsystem
|
|
A fine-grained instance used
for efficient sharing
|
|
An object representing another
object
|
Behavioral Patterns
|
|
A way of passing a request
between a chain of objects
|
|
Encapsulate a command request
as an object
|
|
A way to include language
elements in a program
|
|
Sequentially access the
elements of a collection
|
|
Defines simplified
communication between classes
|
|
Capture and restore an object's
internal state
|
|
A way of notifying change to a
number of classes
|
|
Alter an object's behavior when
its state changes
|
|
Encapsulates an algorithm
inside a class
|
|
Defer the exact steps of an
algorithm to a subclass
|
|
Defines a new operation to a
class without change
|
Definition of singleton pattern
|
Ensure a class has only one instance and
provide a global point of access to it.
|
singleton pattern is a design pattern used to implement
the mathematical concept of a singleton, by
restricting 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 .
Common uses
- The Abstract Factory, Builder,
and Prototype patterns can use Singletons in
their implementation.
- Facade
objects are often Singletons because only one Facade object is required.
- State
objects are often Singletons.
- Singletons
are often preferred to global variables because:
- They
don't pollute the global namespace (or, in languages with namespaces,
their containing namespace) with unnecessary variables
- They
permit lazy allocation and initialization, whereas
global variables in many languages will always consume resources.
Class diagram
Implementation
Implementation of a singleton pattern must satisfy the single instance and
global access principles. It requires a mechanism to access the singleton class
member without creating a class object and a mechanism to persist the value of
class members among class objects. The singleton pattern is implemented by
creating a class with a method that creates a new
instance of the class if one does not exist. If an instance already exists, it
simply returns a reference to that object. To make sure that the object cannot
be instantiated any other way, the constructor is made protected
(not private, because reuse and unit test could need to access the
constructor). Note the distinction between a simple static instance of a class
and a singleton: although a singleton can be implemented as a static instance,
it can also be lazily constructed, requiring no memory or resources until
needed. Another notable difference is that static member classes cannot
implement an interface, unless that interface is simply
a marker. So if the class has to realize a contract expressed by an interface,
it really has to be a singleton.
The singleton pattern must be carefully constructed in multi-threaded applications. If two
threads are to execute the creation method at the same time when a singleton
does not yet exist, they both must check for an instance of the singleton and
then only one should create the new one. If the programming language has
concurrent processing capabilities the method should be constructed to execute
as a mutually exclusive operation.
·
The
classic solution to this problem is to use mutual
exclusion on the class that indicates that the object is being
instantiated.
Traditional
simple way
This solution is thread-safe without requiring special
language constructs, but it may lack the laziness of the one below. The
INSTANCE is created as soon as the Singleton class is initialized. That might even be long
before getInstance() is called. It might be (for example) when some static
method of the class is used. If laziness is not needed or the instance needs to
be created early in the application's execution, or your class has no other static
members or methods that could prompt early initialization (and thus creation of
the instance), this (slightly) simpler solution can be used:
C#
/// <summary>
/// Thread-safe singleton example created at first call
/// </summary>
public sealed class Singleton
{
private static readonly Singleton _instance = new Singleton();
private Singleton() { }
public static Singleton Instance
{
get
{
return _instance;
}
}
}
Abstract Factory definition
|
Provide an interface for creating families
of related or dependent objects without specifying their concrete classes.
|
0 comments:
Post a Comment