Anti-patterns

Anti-pattern[1] is a term first coined by [Gamma95] to mean a common design pitfall. An anti-pattern is called this because many design patterns are designed to avoid such pitfalls.

[1] http://en.wikipedia.org/wiki/Anti-pattern

In other words, design patterns are commonly used solutions to anti-patterns, which are commonly faced problems. Some examples of anti-patterns are:

• Copy and paste programming Copying and modifying existing code without creating more generic solutions.
• Hard coding Embedding assumptions about the environment (such as constant numbers) in multiple parts of the software
• Interface bloat Having too many methods, or too many arguments in functions; in general, refers to a complicated interface that is hard to reuse or implement
• Reinventing the (square) wheel Implementing some code when something (better) already exists in the available APIs
• God Object An object that has too much information or too much responsibility. This can be the result of having too many functions in a single class. It can arise from many situations, but often happens when code for a model and view are combined in the same class.

In Figure 15.1, customer includes member functions for importing and exporting its individual data members in XML format. getWidget() provides a special GUI widget that the user can use to enter data from a graphical application. In addition, there are custom methods for input/output via iostream.

Figure 15.1. Anti-pattern

This class is a model, because it holds onto data and represents some abstract entity. However, this class also contains view code, because of the createWidget() method. In addition, it contains serialization code specific to the data type. That is too much responsibility for a data model. It is quickly becoming an example of the God Object anti-pattern.

As we add other data model classes (Address, ShoppingCart, Catalog, CatalogItem, etc.), each of them also would need these methods:

• createWidget()
• importXML()
• exportXML()
• operator<<()
• operator>>()

This could lead to the use of copy-and-paste programming, another anti-pattern.

If we ever change the data structure, corresponding changes would need to be made to all presentation and I/O methods. Bugs introduced when maintaining this code are very likely.

If Customer were reflective, meaning that it had the ability to determine useful things about its own members (e.g.: How many properties? What are their names? What are their types? How do I load/store them? What are the child objects?), then we could define a generic way to read and write objects that would work for Customer and any other similarly reflective class.