Design pattern

In Computer science, a **Design pattern** is an abstract solution to a certain problem. Design patterns are used in object oriented programming. They give a possible solution to a problem of designing software.

Design patterns became popular around the year 1995. They also simplify the language between computer scientists. Ideally, a design pattern should be reusable many times. It is like a brick of a house, it can be used for many different problems. One can also build bridges with bricks, not only houses.

## Examples 
These examples are actual examples of design patterns as they are in use. They have not been simplified. It is only the language used to describe them that has been made simpler.
### Flyweight 
The flyweight design pattern is used to minimize the use of many similar objects. In a text-processing system each letter can have some attributes like formatting, typeface, and size. While it would be possible to create a new object for each character in the document and give it these attributes, it is extremely expensive.

Instead it would be better to create one object for each type of formatting and link the letter to that information. That needs a lot fewer objects. The only extra information that would need to be stored is the word or letter's position in the document. All similar letters would use the same object to define font, size, and other properties.

### Singleton 
Another easy to understand pattern is called *Singleton*. It is used when there can only be one instance of a given class. That class usually has some static method (e.g. getInstance()) which returns a new instance. It also saves the instance internally. So if it already created the instance, it can simply return it.
 // The Singleton class defines the `GetInstance` method that serves as an
     // alternative to constructor and lets clients access the same instance of
     // this class over and over.
 
     // EN : The Singleton should always be a 'sealed' class to prevent class
     // inheritance through external classes and also through nested classes.
     public sealed class Singleton
     {
         // The Singleton's constructor should always be private to prevent
         // direct construction calls with the `new` operator.
         private Singleton() { }
 
         // The Singleton's instance is stored in a static field. There are
         // multiple ways to initialize this field, all of them have various pros
         // and cons. In this example we'll show the simplest of these ways,
         // which, however, doesn't work really well in multithreaded program.
         private static Singleton instance;
 
         // This is the static method that controls the access to the singleton
         // instance. On the first run, it creates a singleton object and places
         // it into the static field. On subsequent runs, it returns the client
         // existing object stored in the static field.
         public static Singleton GetInstance()
         {
             if (instance == null)
             {
                 instance = new Singleton();
             }
             return instance;
         }
 
         // Finally, any singleton should define some business logic, which can
         // be executed on its instance.
         public void someBusinessLogic()
         {
             // ...
         }
     }
 
     class Program
     {
         static void Main(string[] args)
         {
             // The client code.
             Singleton st1 = Singleton.GetInstance();
             Singleton st2 = Singleton.GetInstance();
 
             if (st1 == st2)
             {
                 Console.WriteLine("Singleton works, both variables contain the same instance.");
             }
             else
             {
                 Console.WriteLine("Singleton failed, variables contain different instances.");
             }
         }
     }