Before we directly jump into defining the principles and talk about the important and most common design patterns, let's question the basics of what designs are patterns and why we should have software development principles.

No individual, group, or organization wants a software product whose code looks complex, hard-to-change, fragile, and nonreusable. All of us want the code to remain flexible, robust, and reusable. Therefore, we follow some of the core design principles that are eventually essential to the quality of a software product.

SOLID design principles are a set of basic OOD design principles. These principles were first published by Robert C. Martin, popularly known as Uncle Bob. He is also a coauthor of the Agile Manifesto.

S.O.L.I.D stands for five primary class design principles:

• Single Responsibility Principle (SRP): A class should have only one reason to change, which means that a class should have only one primary job to do; an extension can be added, for example, inheritance.
• Open Closed Principle (OCP): A class should be designed in such a way that it is open for the extension of its behavior but is closed for modification in itself.
• Liskov Substitution Principle (LSP): All of the derived classes should be substitutable (replaceable) with their parent class.
• Interface Segregation Principle (ISP): Interfaces should be fine-grained and client-specific. Let's say that a client should never be forced to...

In modern coding patterns, factory level containers that help assemble components eventually into a cohesive application have become very important. Beneath such type of containers, there is a common pattern which defines how to perform the wiring of different components together and is known as Inversion of Control (IoC). The pattern coming out of it is more specifically known as Dependency Injection.

Dependency Injection design pattern fulfills the dependency inversion principle of the SOLID design principles. There are three main forms of dependency injection:

• Constructor injection: An example of this is shown in the DIP section
• Setter injection: Let's look at an example code for setter injection:

 ...

Design patterns were formally introduced in the book Design Patterns: Elements of Reusable Object-Oriented Software, first published in 1994 by the four authors Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, with a foreword...

Creational design patterns are those software design patterns that deal with the mechanism of object creation in a flexible, maintainable manner under certain situations or scenarios.

Let's jump on to the individual creational pattern to see its detail.

The singleton pattern is perhaps the most common pattern used by developers across the globe. This pattern basically defines a class for which only one (single) instance can exist.

You can have a class that is either global or static with all static methods so that you do not need to create any instance of this class and use it directly. This is okay but not considered a best practice generally, unless you are defining a stateless interface to expose an underlying OS...

These design patterns are best practices to identify a simple way to realize relationships between entities and their structure in a given situation.

Let's jump on to our selective structural patterns individually to look at their detail.

The adapter pattern, as the name suggests, is the pattern for a class that adapts the interface of another considerably complicated or inconsistent class. It's basically just a wrapper class. It wraps the interface of another class to an interface that is simpler, consistent to the software design, and is what the client is expecting.

The following diagram shows the adapter pattern in general and the one used for our example:

It is one of the simplest GoF design patterns with the purpose...

These design patterns are best practices to identify a simple way to realize relationships between entities in a given situation.

Let's jump on to our selective behavioral patterns one by one in order to see them in detail.

The template method pattern basically defines the steps of an algorithm inside a class as a contract while deferring some of the steps (methods) to be implemented by the derived classes; hence, it primarily defines the structure via an abstract base class.

We will explain its implementation using an example in continuation of our sample for a GUI app we created earlier for the abstract factory pattern. In fact, within the same example app, we cover abstract factory, builder, and template method...

All of these design patterns satisfy the S.O.L.I.D object-oriented design principles. Going through this chapter not only helped you revise your GoF patterns and fundamental S.O.L.I.D principles, but it will also help you keep in mind when you are designing your new classes to solve certain problems and hence increase the quality of your software.

We also covered some fundamentals of Inversion of Control via dependency injection and also went though some examples of DI using .NET Core. You would have also noticed that with the advent of DI, a lot of GoF patterns are automatically taken care of by the DI pattern. For example, almost all of the creational patterns can be replaced by the DI, while for many others, DI can complement them by taking care of part of their responsibility with regards to their implementation.

I hope you enjoyed this chapter as much as I did. This chapter provides the solid and essential...