Introduction to Design Patterns

Design patterns are typical solutions to commonly occurring problems in software design. They are like a blueprint you can customize to solve a recurring design problem in your code. The pattern is not a specific piece of code, but a general concept for solving a particular problem. You can follow the pattern details and implement a solution that suits the realities of your own program.

Never confuse a design pattern to an algorithm; they are totally different. An algorithm is a clear set of actions you must follow in order to solve a particular problem; design pattern is not. A pattern is a more high-level description of a solution. A pattern is more like a blueprint: you can see what the result and its features are, but the exact order of implementation is up to you. I like to see a pattern like a good advice which if you follow will serve you well. But because an advice is good doesn't mean it's the only way to solve a problem.

When a solution gets repeated over and over in various projects, someone eventually puts a name to it and describes the solution in detail. That’s basically how a pattern gets discovered. Design patterns differs by their complexity, level of detail and scale of applicability to the entire system being designed.

The most basic and low-level patterns are often called idioms. They usually apply only to a single programming language. The most universal and high-level patterns are architectural patterns. Developers can implement these patterns in virtually any language. Unlike other patterns, they can be used to design the architecture of an entire application.

This is just an overview of design patterns. I will be writing on some specific design pattern later in this writing series