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.


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.

QMetaObject The MetaObject Pattern

Part I: Introduction to C++ and Qt 4

C++ Introduction


Introduction to Qt



Inheritance and Polymorphism

Part II: Higher-Level Programming


Introduction to Design Patterns


Generics and Containers

Qt GUI Widgets


Validation and Regular Expressions

Parsing XML

Meta Objects, Properties, and Reflective Programming

More Design Patterns

Models and Views

Qt SQL Classes

Part III: C++ Language Reference

Types and Expressions

Scope and Storage Class

Statements and Control Structures

Memory Access

Chapter Summary

Inheritance in Detail

Miscellaneous Topics

Part IV: Programming Assignments

MP3 Jukebox Assignments

Part V: Appendices

MP3 Jukebox Assignments


MP3 Jukebox Assignments

An Introduction to Design Patterns in C++ with Qt 4
An Introduction to Design Patterns in C++ with Qt 4
ISBN: 0131879057
EAN: 2147483647
Year: 2004
Pages: 268 © 2008-2020.
If you may any questions please contact us: