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.5^TM. See our Singleton page for a .NET 3.5 Optimized code sample.

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

 

 

Definition of singleton pattern

Ensure a class has only one instance and provide a global point of access to it.

• 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.

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.

The usual catalog of relational normal forms lists five of them. They are called, reasonably enough, first, second, third, fourth and fifth normal forms (abbreviated here as 1NF, 2NF and so on). These normal forms fall into two groups. The normal forms in the first group are defined in terms of functional dependencies – a concept that will be explained later. Those in the second group are defined in terms of multi-valued dependencies and lossless joins. I will call the first group the “basic” normal forms and the second group the “advanced” normal forms.
Practitioners often claim that if a data model is in 3NF, it is “fully normalized.” This claim appears to be based on the belief that violations of 4NF or 5NF are only found in academic discussions of normalization and do not occur in real-world data models. But violations of 4NF and 5NF do appear in real-world data models, although less frequently than violations of the basic normal forms.
When violations of the advanced normal forms do occur, they are generally difficult to recognize. But as with all the normal forms, we must still either remove the violations from the data model or else write maintenance code to insure that they do not cause inconsistencies in the database. If we do not remove the violation of the normal form, then we must write maintenance code, which insures that all inserts, updates and deletes, apply to all of the multiple copies of the same fact. In this way, the database is maintained in a consistent state, in spite of the fact that the same fact is recorded multiple times. If we cannot even recognize violations of 4NF and 5NF, then we will not be able to either remove the flaw from our data models or write maintenance code to protect the database against inconsistencies.
In this series, I will review only the basic normal forms, leaving discussion of the advanced normal forms for a later series. In addition to 1NF, 2NF and 3NF, I will review an “improved” 3NF, called Boyce-Codd normal form (BCNF), which is where the line should be drawn between the basic and the advanced normal forms. This is important to understand because the frequently occurring, easy-to-recognize violations of normalization are based on the redundant expression of functional dependencies, and a database in 3NF may still contain such violations. A database in BCNF, however, is guaranteed to contain no violations based on functional dependencies.

Nearly everyone who has heard of relational databases has heard of normalization and knows that a principal objective of relational data modeling is to produce a “fully normalized” data model. The value of a fully normalized model is that it minimizes redundancy in a database, and thereby makes it less likely that inconsistencies can appear in that database. There are thus specific benefits to be gained from an understanding of the process of normalization and of how it applies in the IT environment.
Normalization removes redundancies from relational data models. Redundancy in a data model means that the same fact can be recorded multiple times in a database that conforms to that data model. If the different copies of that fact are not all entered correctly into the database, or if they are not all updated the same way, at the same time, then the database will be inconsistent with respect to that fact.
Normalization also eliminates the dependency of one fact on another. If one piece of information is removed from a database, this should not force the removal of a separate piece of information. When the last employee is transferred out of department ITSP, the name of that department, “Information Technology Strategic Planning,” should not be removed from the database. The name of a department is a piece of information which is separate from the list of employees who belong to that department and should not disappear when the list becomes temporarily empty.
A third benefit of normalization is that it assists in the discovery and clarification of business rules. In the process of normalizing a data model, we are forced to get answers to questions such as, “Can a salesperson be recorded in the database even if she currently is not assigned to any customers?” These answers are business rules, and requirements gathering done in advance of building a data model will never uncover all of these rules.
There are several good books that discuss normalization. For example, years ago, in the third edition of his classic work, An Introduction to Database Systems, Chris Date¹ included an excellent chapter on normalization. And there are now many other books on the subject, each with their own particular merits.
This series of articles will review the basic normal forms. These are the ones that are based on the concept of functional dependencies. No background in relational data modeling is assumed, but the topic will be covered in depth. In the last article in the series, I will provide a management-level summary of all the material presented in the earlier articles.
With respect to data modeling theory, I will define the concepts of normalization and the normal forms themselves as precisely as possible. When the definitions involve technical concepts such as those of superkeys and functional dependencies, I will do more than give a concise mathematical definition of the concepts. Instead, I will make those concepts intuitive by explaining why and how they work.

With respect to data modeling practice, my approach will include multiple solutions to many of the normalization problems I will discuss and show how the different solutions support often subtle differences in business rules. Thus, these articles will not be merely a review of the basic normal forms. They will show those normal forms at work, and illustrate how a modeler uses the rules of normalization to think through real-world modeling problems.