UNISA Chatter – Design Patterns in C++ Part 9: Patterns Revisited

See UNISA – Summary of 2010 Posts for a list of related UNISA posts. This post is one of the summary posts I will be building up over the next couple of months, so if you are following this topic or completing the same course as I this year, you may want to bookmark this post and come back occasionally for a peek and to give “candid” feedback.

If you are not studying at UNISA, this material summary is probably best skipped for more interesting topics … :)

In this post we will summarize all of the patterns we encountered in this module to date … an annual cheat sheet :) As mentioned before , you best refer to the book “Gang of Four” for the complete story. In essence we have three main categories of patterns that define a name, a description, an abstract description of the design problem and discussion on pros and cons of patterns:

Anti-Patterns

In Visual Studio 2010 Architecture Guidance – What is a 4+1 View? we mentioned the anti to what we are covering in this post … anti-patterns, such as:

• Copy and paste programming
• Hard coding … embedding constants and other assumptions
• Bloated interfaces … the interfaces with all the methods
• God objects … which know everything and do everything
• Reinventing the wheel … instead of re-using and optionally extending existing functionality

Creational Patterns – management of objects

Sorry for some rough images, which are mostly scans from my notes.

Pattern	Description	Model View
Abstract Factory	Provides an interface for defining factories. Factories share abstract features, but differ in their implementation. Clients can instantiate objects of a factory via the abstract interface. Factory itself is typically a singleton, not using statics. If we were to use static instead of sitting on the heap, the factory may be destroyed after the main application … as would be the case with QT … a potentially fatal situation.
Monostate	Allows multiple instances of an application to share the same one (mono) state. It is an implementation of the Singleton pattern.

Structural Patterns – connection of objects to form more complex objects

Pattern	Description	Model View
Adapter	An adapter is a wrapper that translates one interface to another, primarily to conform to a compatible interface.
Composite	Facilitate building complex (composite) objects from simpler (component) objects and representing the whole-part hierarchies as tree-like structures. Think of an airport, made up of planes, which in turn are made up of plane parts.

Behavioural Patterns – organization of code and object communication

Pattern	Description	Model View
Command	Encapsulates commands/operations  in as objects with a common interface, making it possible to operations, log operations and implement features such as undo, redo and transactions.
Serializer	A serializer object is only responsible for reading and writing objects, which encapsulates the read/write logic , therefore making it easier to change the object format and promoting maintainability. An example is the QDataStream class, which allows serialization and deserialization of all QVariant supported types, such as QList, QMap, QVector, etc.
Strategy	A strategy pattern allows algorithms (concrete implementations) to be selected at runtime, using reflection or polymorphism.
Visitor	Describes how to separate code for re-use, keeping a clear separation between an algorithm (logic) from an object structure that the algorithm operates on. This approach allows us to extend the feature set of operations of an existing object ecosystem without changing the ecosystem (plumbing). It is a way of separating operations to be performed on selected objects in some organised collection.

Architectural Pattern

Pattern	Description	Model View
Model-View-Controller	The MVC pattern isolates the application logic, from the input and presentation (UI) logic. Model … manages information and notifies observers when the information changes. View … renders the model into an interaction form, for example the user interface. Controller … receives input from the user and controls the model and views to perform appropriate actions.

QT Notes made in the last two weeks

• QT Controller classes include QApplication and QAction.
• InputField servers as an adapter, to a platter of input widgets that do not have a common QVariant interface.
• InputField uses the strategy pattern to organize the getters and setters for different types as virtual functions.
• Widgets
  • QTreeView
  • QListView
    • QListViewItemIterator can be used to iterate through the list, for example, to find selected items.QTableView
• QModelIndex can be used as an index into item models derived from QAbstractItemModel.

Next in line is a project that consolidates, combines, uses and explores all of the above … I am looking forward to it as we are nearing the end of the nightly excursions and studying.