Table of Contents
- Special Member Functions: Constructors, Destructors, and the Assignment Operator
- Operator Overloading
- Memory Management
- Time and Date Library
- Object-Oriented Programming and Design Principles
- The Standard Template Library (STL) and Generic Programming
- Exception Handling
- Runtime Type Information (RTTI)
- Signal Processing
- Creating Persistent Objects
- Bit Fields
- New Cast Operators
- Environment Variables
- Variadic Functions
- Pointers to Functions
- Function Objects
- Pointers to Members
- Lock Files
- Design Patterns
- Dynamic Linking
- Tips and Techniques
- Five Things You Need to Know About C++11 Unions
- A Tour of C99
- A Tour of C1X
- C++0X: The New Face of Standard C++
- C++0x Concurrency
- The Reflecting Circle
- We Have Mail
- The Soapbox
- Numeric Types and Arithmetic
- Locales and Internationalization
Last updated Jan 1, 2003.
Design patterns are recommended solutions to recurring problems. The pattern movement also identifies and catalogs anti-patterns. Unfortunately, anti-patterns are more widespread than patterns, and their impact on software projects is much more noticeable. Today, I explain what anti-patterns are, and present some of them.
What is an Anti-pattern?
According to Jim Coplien, "an anti-pattern is something that looks like a good idea, but which backfires badly when applied." In other words, it's a recipe for doing things the wrong way.
Unlike patterns, anti-patterns aren't restricted to design and implementation phases. They may stem from personal, organizational, and financial factors.
The History Book on the Shelf...
It's no secret that the majority of software projects fail. Assuming that the causes of failure aren't unique to each project, why aren't we witnessing a decline in the failure rate? It appears that people can't always put their finger on the ultimate cause of the problem. Developers and project managers can consult the anti-pattern catalog, identify these problems and learn how to cope with them effectively.
...Is Almost Repeating itself
It is possible to come up with high quality software solutions even if you don't use patterns. However, the very presence of anti-patterns in a software project usually entails poor quality and problematic maintenance, or even an utter failure Thus, identifying and averting anti-patterns pays off more than would throwing in a few normative patterns.
Anti-patterns can be classified into subcategories, e.g., language-specific anti-patterns, for example, template- and exception-related anti-patterns), analysis and design anti-patterns, and organizational anti-patterns. Let's look at a sample of such anti-patterns. Does any of these look suspiciously familiar?
Certain coding practices and language-specific features lend themselves easily to misuse. Exception funneling is one such example.
Exceptions usually occur in low-level routines that should not try to fix the problem. These routines propagate the exceptions upwards until an appropriate handler catches the exception.
In a large-scale project, designers may be tempted to collapse various exception types into a single general exception. It's done for a couple of reasons. Either they don't want to confuse the users with technical details. Or the design phase deals only with the best case scenarios, and during the implementation phase, exception handling are only done to ensure that the code doesn't crash.
Programmers who conceive exceptions as rare and hopeless runtime errors tend to use this anti-pattern frequently. As a result, when an exception occurs, it's hard to know what exactly happened. They need to debug the application, reconstruct the call stack, and locate the code section that throws the exception.
In some cases, avoiding exceptions altogether and using an alternative method for reporting failures is preferable. For example, STL algorithms such as find() return an agreed-upon iterator value that indicate "not found." In other scenarios, a through design of exception types and the responsibility for handling them is necessary to avert this anti-pattern
Analysis and Design Anti-patterns
The following anti-patterns depend on the analysis and design phases rather than the actual programming language used.
A God Object is an object that knows too much or does too much. Procedural programmers making the migration to an object-oriented environment tend to treat the the notion of a class as the equivalent of a complete program: they design a class that knows everything about everything and has dozens of data members. Often, such poor design leads to the instantiation of a single (usually global) object of this class. Every function call and if-condition has to use this object, update its state, and depend on its gigantic interface.
Analysis Paralysis is a pathological state in which a team of analysts begin the analysis phase but never finishes it. In many cases, this leads to the project's cancellation. What are the causes of this? Sometimes, the analysts have no experience in developing software. Consequently, they never soar beyond the diagrams and charts stage. In other cases, the project's requirements aren't clear or they are conflicting. One solution is to employ developers who are also analysts, not analysts who haven't developed before.
Poor managerial skills, egotism, and lack of collaboration lead to recurring delays, additional costs and poor quality software.
This management anti-pattern occurs when the boss seems to have chosen a successor. Although this decision isn't publicized officially, everyone mutters the successor's name. Consequently, senior team members leave the project as an act of protest. The subversive undercurrents stirred by other disgruntled team members also shift the focus from the development phase to a political campaign.
Managers should realize that "clandestine coronations" become common knowledge very quickly. It's therefore better to appoint a successor in an open process that gives other candidates a fair chance. Remember: even when the successor is elected in an open process, other team members might leave. If you can't afford to lose them, perhaps the best idea is to postpone the coronation to a less critical phase in the project.
The small number of anti-patterns (a few dozens) compared to the huge number of failed projects suggests that on average, each anti-pattern has occurred hundreds of times before. Familiarity with the anti-pattern catalog can thus teach managers and developers alike which mistakes they should avoid.
The anti-pattern catalog is an incomplete list of some of the more popular and documented anti-patterns. Although the items are presented in fluctuating levels of depth and details, this catalog is pretty exhaustive.
Wikipedia also provides a detailed catalog of anti-patterns.