7.4.2. AntiPatterns

7.4.2. AntiPatterns
	7.4. Design Patterns

[ fromfile: antipatterns.xml id: antipatterns ]

AntiPattern is a term first coined by [Koenig95] to describe a commonly used programming practice that has proved to be ineffective, inefficient, or otherwise counterproductive.
There is an informative and evolving article on this subject in Wikipedia that organizes and briefly describes a substantial number of antiPatterns.
Following is a small selection of named antiPatterns from the Wikipedia article.
- Software design antiPatterns
  - Input kludge: Failing to specify and implement the handling of possibly invalid input.
  - Interface bloat: Making an interface so powerful and complicated that is hard to reuse or implement.
  - Race hazard: Failing to see the consequence of different orders of events.
- Object-oriented design antiPatterns
  - Circular dependency: Introducing unnecessary direct or indirect mutual dependencies between objects or software modules.
  - 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.
- Programming antiPatterns
  - Hard coding: Embedding assumptions about the environment of a system in its implementation.
  - Magic numbers: Including unexplained numbers in algorithms.
  - Magic strings: Including literal strings in code, for comparisons, as event types etc.
- Methodological antiPatterns
  - Copy and paste programming: Copying and modifying existing code without creating more generic solutions.
  - Reinventing the (square) wheel: Failing to adopt an existing, adequate solution and, instead, adopting a custom solution (which performs much worse than the existing one).

In Figure 7.2, Customer includes several I/O functions.

Figure 7.2. AntiPattern Example

This class is a model (holds data and represents a customer entity).
This class is a view (contains GUI member functions).
This class contains serialization functions for particular I/O streams.
This is an example of the Interface Bloat antiPattern (and perhaps a few others also).

Suppose you want to implement classes like these:
- Address
- ShoppingCart
- Catalog
- CatalogItem
- etc.
Each of them would also need these methods:
- createWidget()
- importXML()
- exportXML()
- operator<<()
- operator>>()
This could lead to the use of Copy-and-Paste programming, another antiPattern.

If you ever change the data structure, corresponding changes would need to be made to all presentation and I/O methods.
Bugs are likely to be introduced when maintaining this code.
Chapter 12 discusses an example that shows how to write more general-purpose code with reflection.


7.4.1. Serializer Pattern: QTextStream and QDataStream		7.4.2.1. Points of Departure