Design patterns

Nowadays in the world of software engineering the problems are getting more complex. Luckily for us there are proven solutions for parts we need to solve. These proven solutions we call design patterns.

At least a design pattern contains a name, description, what problem is solves, the advantages and disadvantages and also the solution. The most famous book, pretty good book to learn design, is the book written by the Gang of Four. This book describes a classic set of patterns which are most used today. Patterns like Model-View-Controller (MVC), Observer, Factory and Iterator. Even if you think you didn’t used design patterns in the past, lots of them are embedded in the new generation programming platforms nowadays like Java and .NET. So you should be familiar with them already.

Using design patterns only doesn’t mean the perfect software

If you like to use design patterns, remember that a pattern isn’t the law. You can adapt and combine them the way you like. Also don’t use a pattern just to use it. You really have to make sure why you need the pattern to be included in your solution and if it doesn’t conflict with other patterns you’re using.

In example look to the functionality that the platform you use to build your software upon is providing. Reuse as much of these functionality as you can, it’s cheaper (saves time), is probably better (proven technology) and easier (most of the time well documented in a API).

O no, anti-patterns….

Anti-patterns are the opposite of the normal patterns, but even more implemented! Think like patterns as the Singleton, Gold plating (a.k.a. Design by Committee) and Reinvent the Wheel

In example a Singleton (which makes sure you can have only one instance at the lifetime of the object) makes testing of the using classes hard to even impossible. If the Singleton object stores data, this data can be accessed and probably changed by any object at anytime. In the end the data can’t be trusted.
If the design forces to have one and only one instance of an object, you can provide this functionality by a Factory. The Factory class is responsible create and destroy the object. For testing purposes a mock (a stub class) can take the place of the read singleton object. This makes testing available.

Further reading

If you really like to know more about patterns and anti patterns, you can read further on the following links or the links at the used sources.

Used sources

    Liked what you read? Share this!