Over the next couple weeks I'm going to be writing a series on programming design patterns and their applications. I plan to cover the popular patterns as well as the lesser-known, yet still insanely useful, ones too. This first article will go over the background and basics of a design pattern - What they are, why you should care, and how to implement one into your application.
What are design patterns?
Design patterns, described very simply, solve reoccurring problems in the programming world. Most problems encountered by programmers have been solved, usually more than once by others. Having the ability to take advantage of code that has already been written is invaluable to a developer's time and sanity. This does not include a login system for your website. Think on a much smaller scale.
In the world of software, a pattern is a tangible manifestation of an organization's tribal memory.
-Grady Booch
Patterns are not designed to be complete solutions. Rather, they give you a very solid foundation from which to build upon. Patterns are somewhat intangible and difficult to describe to someone who has not dealt with them before. The best way I can describe them in layman's terms is that they are reoccurring outlines of code that is not solidly defined. That is to say, the contents of the pattern can change but the fashion in which they are laid out and executed is consistent from use to use.
Why should I care?
Patterns are, intentionally, loosely defined. However, the problem each pattern tries to solve is extremely useful. Since these problems can be found in almost every application across numerous programming languages, patterns give programmers a way to understand each other's code without knowing the syntax. If I (a PHP developer) told a Java, Python, or .NET developer that I used a Factory Pattern to solve my problem, they would know exactly what I meant, what the problem was, and the possible consequences of my solution. The value of this point can not be underestimated.
Patterns have been, for the most part, clearly defined by the programming universe. Their pros and cons have been spelled out and agreed upon. Of course there are dissenting opinions about some of these but such is the spice of life. To be clear, the pattern itself is almost always the same from developer to developer, however the appropriate environment in which it should be used it always a matter of debate.
Key Points: A Pattern..
- Defines a problem.
- Defines a solution.
- Are language independent.
- Define a vocabulary.
- Are tried and tested.
- Designed for collaboration.
- Promote good design.
Enough talk, let's see a pattern
Not so fast. I've found it absolutely crucial to recognize the fact that design patterns are only generic solutions to common problems. Developer's often, after learning about patterns, catch themselves looking for problems that a pattern could solve. Don't force a pattern into your application where the benefits are negligable or worse. When you have a hammer, everything looks like a nail.
My next article will introduce one of the most basic, useful, and widely used patterns: The Singleton Pattern.
Click here for the next article in the series: The Singleton!
Comments
No comments yet. Be the first!