Design Patterns
Design Patterns are incredibly useful to software engineers, helping them save time and effort while coding. In software engineering, design patterns are specifically general, reusable solutions to common problems in computer science. However, it is not a solution formatted to be used as a finished design that can be translated directly into source or machine code, but more of a template or description for how to solve a problem in many different situations. It can be conceptualized as landing somewhere in between programming paradigms and a concrete algorithm, and because of its ambiguous yet widely-applicable nature, a design pattern not only makes programmers’ lives easier but it can make their work better, as well:
In a recent review study, Wedyan and Abufakher investigate design patterns and software quality and conclude: "Our study has shown that the primary studies provide an empirical evidence on the positive effect of documentation of designs pattern instances on program comprehension, and therefore, maintainability. While this result is not surprising, it has, however, two indications. First, developers should pay more effort to add such documentation, even if in the form of simple comments in the source code. Second, when comparing results of different studies, the effect of documentation has to be considered."
Since computer science is incredibly powerful, complex, and far-reaching, there are countless problems that can be encountered, and a number of design patterns that, while doesn’t quite measure up, is sizable. Therefore, in this post I will only mention a few, important ones, and give a brief description (it’s very easy to go too in-depth about these concepts, so similarly to the method I employed in my last blog post, I will include links providing further information about each of these design patterns.
One common design pattern is the Singleton Pattern. This pattern restricts the instantiation of a class to one "single" instance, which is useful when exactly one object is needed to coordinate actions across the system. Since it’s more of an idea or way of implementation than a ready-to-use code, it does take some adaptation, but nevertheless it can be a huge help to any programmer that is running into the problem it addresses.
Another pattern is the Builder design pattern. This is designed to provide a flexible solution to various object creation problems in object-oriented programming, intended to separate the construction of a complex object from its representation. It can solve problems like how a class can create different representations of a complex object, or how a class that includes creating a complex object can be simplified.
The Factory design pattern is is a creational pattern that uses factory methods to deal with the problem of creating objects without having to specify the exact class of the object that will be created. This is done by creating objects by calling a factory method, which is either specified in an interface and implemented by child classes, or implemented in a base class and optionally overridden by derived classes
The Strategy Design Pattern is a behavioral software design pattern that enables selecting an algorithm at runtime. Instead of implementing a single algorithm directly, code receives run-time instructions as to which in a family of algorithms to use.
These four design patterns are among the most common, especially in programs that deal with classes and object-oriented programming. There are a number of other patterns, such as Facade, Decorator, Proxy, MVC (Model-View-Controller), Circuit Breaker, Event Sourcing, and CQRS, which also address common problems, and these “templates” can be lifesavers when running into tricky issues. Most of these patterns are also Gang of Four patterns, which is a collection of 23 design patterns described in a book by four authors: Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (hence the name).