Even though computer science is a relatively young discipline, typically thought of as highly dynamic and thus eluding the constraints of standards and specifications, anyone who works in the field long enough will begin to see recurring patterns, both for good and bad solutions. In this article, Stefan describes the evil practises in software engineering.

Even though computer science is a relatively young discipline, typically thought of as highly dynamic and thus eluding the constraints of standards and specifications, anyone who works in the field long enough will begin to see recurring patterns, both for good and bad solutions.

If you’re involved in IT, you’ve likely heard of design patterns. In the lecture room, in specialist publications, in discussions within the design team - sooner or later you start to notice that your own observations are shared by your colleagues. Design patterns provide a set of recipes for tried and tested solutions to typical problems encountered when developing software systems. Before I define what an antipattern is, allow me to recap briefly on the short yet eventful history of design pattern studies.

As you will likely remember if you’re familiar with the development of object-oriented design and the patterns associated with it, the idea of using a common pattern language in software development was initially presented in 1987 by Kent Beck and Ward Cunningham, but was inspired by a monumental work from a completely different area. Christopher Alexander’s A pattern language, a book on patterns in architectural design, was the publication that introduced the key notions of design pattern studies and thus earned its place in the history of software engineering. Alexander’s ideas were eagerly taken up by programmers, who had long been looking for ways to avoid writing boilerplate code, provide systematic descriptions for known solutions and allow effective transfer of knowledge within design teams. With the first online communities just appearing, the atmosphere was ripe for the creation of the classic book Design Patterns: Elements of Reusable Object-Oriented Software by Gamma, Helm, Johnson and Vlissides, commonly known as the Gang of Four. The book presents detailed solutions to typical design problems, with examples in C++ and Smalltalk.

The idea of design patterns was quickly taken up by developers using diverse technologies and environments, veterans and beginners alike. The list of common patterns is still being extended, but its nemesis - the blacklist of evil practices - is also becoming ever more important. Creating a list of bad design practices proved necessary mainly due to the misapplication of good practices. Some of the first antipatterns to be described resulted from the misuse of existing knowledge concerning desirable solutions. The growing popularity of design patterns and object-oriented design among inexperienced developers provided material for a blacklist of design practices. Initially, the list was created within the first Wiki system on the Internet at http://www.c2.com/, where developers shared their experience of design patterns. The antipattern catalogue available there served as reference both for this article and a number of existing publications on the subject.

What is an antipattern?

The introduction presented above suggests that antipatterns are primarily misapplied design patterns, but that’s only part of the story. The first systematic attempts at describing design antipatterns were indeed focussed primarily on highlighting a design feature or piece of code that corresponded to one of the popular patterns, but was used in the wrong context, resulting in a design flaw and often erroneous results. Steps were also suggested to remedy such flaws and refactor the problematic code to arrive at the correct pattern.

Figure 1 shows both the process of correct pattern application and the process of identifying and refactoring a system that contains antipatterns.

Figure 1. Patterns and antipatterns in practice

As the number of recognised antipatterns grew, it became clear that while some indeed result from the misapplication of patterns, many others arise from bad practices in project management and the misuse of development tools. At present it is hard to say exactly what constitutes an antipattern and what doesn’t, but the general consensus is that an antipattern description should outline a bad solution and suggest a way out of it.

Design antipattern classification

A programmer will look at code problems from a different perspective to a systems architect or project manager, as each of them deals with a software project on a different level. This implies a natural division of antipatterns into three principal types, as illustrated in Figure 2.

The first category are programming antipatterns, where it is up to the programmer to look for a way out of the fix. Next come design antipatterns, where it is the system architecture and the consequences of putting it into practice that create the need to refactor. Last but not least are project management antipatterns - ones that involve the development team itself and the roles assigned to its members, though also covering such global technical aspects as code management or documentation.

This threefold division was outlined in one of the key publications on design antipatterns: the book AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis, published in 1998. This article focusses primarily on coding antipatterns.

Why learn antipatterns?

Before we go on to examine why antipatterns come about and look at some common antipatterns, let’s stop to think about why knowing them might be useful in the first place. There is no doubt that knowing and correctly applying design patterns can help developers create a robust system that fulfils user requirements. However, if you’re not entirely sure what pattern to use, then being aware of the potential pitfalls can also help. While the examples included in antipattern descriptions are usually anecdotal, it’s definitely best to avoid replicating them in actual software.

If for whatever reason you find yourself faced with code that needs refactoring, then a knowledge of antipatterns will help you find the best way out of the problem. Drawing on the knowledge and experience of other software developers and designers minimises the effort required to create software that follows best practices for the industry.

sum:

0 €

» Library of the Month
» Workshop
» Software Engineering
» Programming Tools
» Interview
» High quality and
secure programming
» Reverse Engineering
» Portable GUI
» Artificial intelligence