Design Patterns

In software engineering, design patterns are software development patterns that make code re-usable and less bug-prone. These are tried and tested patterns that fit in particular scenarios.

This post is evolving and will have series linked to this original post. Keep watching this space for updates

Design patterns are the template to tell us how to solve a problem in similar scenarios

The elements of this language are entities called patterns. Each pattern describes a problem that occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. — Christopher Alexander (from Wikipedia)

Thinking out Loud

Uses

Design patterns help us speed up the development by providing tested, proven development paradigms. Software design requires foreseeing issues that may not become visible until later in the project phase.

Using design patterns helps to prevent issues that can cause major problems. Design problem also helps in making code readable and more predictable for developers as most of them would be familiar with existing patterns than ad-hoc designs.

Additionally, design patterns allow developers to communicate using well-known, well-understood names for software interactions. Common design patterns can be improved over time, making them more robust than ad-hoc designs.

Design patterns can be broken into three categories broadly. In this section, we would be categorizing popular design patterns and we may discuss them in detail in subsequent sections.

Creational Design Patterns

As the name suggests, these design patterns are one associated with the initialization of class, object, or modules. The implementation of these patterns depends on the type of programming language and grammar used therein. Here are few design patterns falling into this category

Structural Design Patterns

These design patterns tell us how to compose Classes and Objects to create complex entities. These also help us in identifying relationships among entities and obtain new functionality. These design patterns encourage a developer to design smaller entity based on single responsibility principal

Behavioral Design Patterns

In software engineering, behavioral design patterns are design patterns that identify common communication patterns among objects and realize these patterns. This enhances flexibility in carrying out communication

Criticism

Design Patterns while being popular in the field of Computer Science, but at the same time, it has been criticized by some. Here are some popular criticisms:

Design Patterns are Lazy Design

Contemporary programmers often copy-paste code without considering its implications, sometimes specific to a particular programming paradigm. These are not suitable for other programming paradigms. Most problems are unique and complex while design patterns are simple and re-usable. [Rething Design Patterns]

One size does not fit all

Some design pattern targets shortcoming of a programming paradigm and is specific to those programming paradigms. Design Pattern tries to fit them to other paradigm and that can disastrous. (e.g iterator pattern is different for functional and OOP paradigms)

Peter Norvig provides a similar argument. He demonstrates that 16 out of the 23 patterns in the Design Patterns book (which is primarily focused on C++) are simplified or eliminated (via direct language support) in Lisp or Dylan. Peter Norvig also points out that over half of the design patterns in the 1994 book are workarounds for missing language features.

Common Designs may be Bad Designs

Just because something is commonly used doesn’t make it a good idea. It could be bad, or even disastrous. Singletons, for example, are sometimes seen as trying to avoid object-orient design [Design Patterns: Magic or Myth?]

Design Patterns Increase Complexity

Using inappropriate patterns can be like trying to force a square peg into a round hole: adding additional work and unnecessary dependencies. Some of the modern dynamic languages do not even implement classes or do not fall under OOPs paradigm [Design Patterns Suck].


Please follow to keep watching for new posts. Thanks for reading