Tag: .NET

The numbers of design patterns are less than English alphabets. Twenty-three design patterns are featured in the GoF design patterns book, falling within one of three subgroups: Creational, Structural, or Behavioral.

Creational

Creational patterns deal with object construction and referencing. They abstract away the responsibility of instantiating instances of objects from the client, thus keeping code loosely coupled and the responsibility of creating complex objects in one place adhering to the Single Responsibility and Separation of Concerns principles.

Following are the patterns in the Creational group:

➤➤ Abstract Factory: Provides an interface to create families of related objects.

➤➤ Factory: Enables a class to delegate the responsibility of creating a valid object.

➤➤ Builder: Enables various versions of an object to be constructed by separating the construction for the object itself.

➤➤ Prototype: Allows classes to be copied or cloned from a prototype instance rather than creating new instances.

➤➤ Singleton: Enables a class to be instantiated once with a single global point of access to it.

Structural

Structural patterns deal with the composition and relationships of objects to fulfill the needs of Larger systems.

Following are the patterns in the Structural group:

➤➤ Adapter: Enables classes of incompatible interfaces to be used together.

➤➤ Bridge: Separates an abstraction from its implementation, allowing implementations andabstractions to vary independently of one another.

➤➤ Composite: Allows a group of objects representing hierarchies to be treated in the same way as a single instance of an object.

➤➤ Decorator: Can dynamically surround a class and extend its behavior.

➤➤ Facade: Provides a simple interface and controls access to a series of complicated interfaces and subsystems.

➤➤ Flyweight: Provides a way to share data among many small classes in an efficient manner.

➤➤ Proxy: Provides a placeholder to a more complex class that is costly to instantiate.

Behavioral

Behavioral patterns deal with the communication between objects in terms of responsibility and algorithms. The patterns in this group encapsulate complex behavior and abstract it away from the flow of control of a system, thus enabling complex systems to be easily understood and maintained.

Following are the patterns in the Behavioral group:

➤➤ Chain of Responsibility: Allows commands to be chained together dynamically to handle arequest.

➤➤ Command: Encapsulates a method as an object and separates the execution of a command from its invoker.

➤➤ Interpreter: Specifies how to evaluate sentences in a language.

➤➤ Iterator: Provides a way to navigate a collection in a formalized manner.

➤➤ Mediator: Defines an object that allows communication between two other objects without them knowing about one another.

➤➤ Memento: Allows you to restore an object to its previous state.

➤➤ Observer: Defines the way one or more classes can be alerted to a change in another class.

➤➤ State: Allows an object to alter its behavior by delegating to a separate and changeable state object.

➤➤ Strategy: Enables an algorithm to be encapsulated within a class and switched at run time to alter an object’s behavior.

➤➤ Template Method: Defines the control of flow of an algorithm but allows subclasses to override or implement execution steps.

➤➤ Visitor: Enables new functionality to be performed on a class without affecting its structure.

There are so many design patterns to choose from, so how do you identify which one is appropriate for your problem? To know which design pattern to use and how to apply the solution template to your specific problem, it’s important to understand these guidelines.

➤➤ Patterns can’t be applied without knowing about them. The first important step is to expand your knowledge and study patterns and principles both in the abstract and concrete form. You can implement a pattern in many ways. The more you see different implementations of patterns, the more you will understand the intent of the pattern and how a single pattern can have varying implementations.

➤➤ Do you need to introduce the complexity of a design pattern? It’s common for developers to try to use a pattern to solve every problem. You always need to weigh the upfront time needed to implement a pattern for the benefit that it’s going to give. Remember the KISS principle: Keep It Simple, Stupid.

➤➤ Generalize your problem; identify the issues you’re facing in a more abstract manner. Remember that design patterns are high-level solutions; try to abstract your problem, and don’t focus too hard on the details of your specific issue. Try to keep a list of intent of each pattern and principle in your implementation for reference.

➤➤ Look at patterns of a similar nature and patterns in the same group. Just because you have used a pattern before doesn’t mean it will always be the correct pattern choice when solving a problem.

➤➤ Look at what will likely change with your application and encapsulate what varies. If you know that a special offer discount algorithm will change over time, look for a pattern that will help you change it without impacting the rest of your application.

➤➤ After you have chosen a design pattern, ensure that you use the language of your pattern along with the language of the domain when naming the participants in a solution. For example, if you are using the strategy pattern to provide a solution for costing various shipping couriers, name them accordingly, such as USPSCostStrategy. By using the pattern’s common vocabulary along with the language of your domain, you will immediately make your code more readable and understandable to other developers with patterns knowledge.
When it comes to design patterns, there is no substitute for studying.  A great learning exercise is to try to identify patterns in the .NET Framework. For example, the ASP.NET Cache uses the Singleton pattern; creating a new Guid uses the Factory pattern; the .NET 2 XML classes use the Factory pattern.

Shallow Copy

We can easily achieve a shallow copy of our pizzas list with any of the methods from the previous section. But a shallow copy of a List<T>, where T is a reference type, copies only the structure of the collection and references to its elements, not the elements themselves. This means that changes to the elements in any of the two lists will be reflected in both the original and copied lists.

Let’s illustrate this:

var clonedPizzas = pizzas.ToList();

var margherita = pizzas
    .FirstOrDefault(x => x.Name == "Margherita");

margherita.Toppings.Clear();

First, we create a clonedPizzas variable and clone the contents of pizzas to it using the ToList method (using any of the other methods used earlier will produce the same result). Then we get the Margherita pizza from the original list using the FirstOrDefault method. Finally, we use the Clear method to empty the list of Toppings for that pizza.

Now, let’s see what happens:

Console.WriteLine($"Original Margherita: {pizzas.First()}");
Console.WriteLine($"Cloned with ToList: {clonedPizzas.First()}");

We print the first pizza of each list to the console, which in both cases is the Margherita, using the First method.

We overrode the ToString method which will give us an easy-to-read representation of each pizza. Now, we can check the result:

Original Margherita: Pizza name: Margherita; Toppings:
Cloned with ToList: Pizza name: Margherita; Toppings:

We can see that both the original and copied Margherita pizzas now have an empty list of Toppings. This is because when creating a shallow copy, we only clone the references to the objects, not the actual objects. This is not ideal because when we change elements in one list, we change the elements everywhere we have copied that list.

This might cause serious problems for us, so let’s what we can do to prevent it. Read more here.