Patterns Used

Design Patterns

If you only have time to take a look at one pattern in the whole project, please take a look at csingletonmanager.h! It's probably the most unusual (and perhaps questionable) part of the whole project and I spent some time trying to document it.

Singleton

• CDebug - Basic singleton that instantiates on first use.

• CGame - Singleton that instantiates on call to static method CGame::init(), destructs on call to CGame::deinit().

• CSingletonManager - Parameterized class (i.e. C++ template) for managing a polymorphic singleton whose class can change at runtime. Actualizations of this class are CTimerSystemManager, CEventSystemManager, and CVideoSystemManager. These classes just manage the singleton by providing static accessor, initialization and deinitialization methods; the actual implementation is handled by concrete implementation of the abstract classes listed next.

• CTimerSystem, CEventSystem, CVideoSystem - These are abstract singletons which have no static methods. The static methods are provided for them by the CSingletonManager template instantiations listed above. For an in-depth description of this framework, see csingletonmanager.h.

Abstract Factory

• CSingletonFactory - This template is part of the polymorphic singleton framework and is instantiated in CTimerSystemFactory, CEventSystemFactory, and CVideoSystemFactory. See csingletonmanager.h for more information.

• CVideoSystem - The CVideoSystem::make_csurface_impl() methods create platform-specific bitmap surface implementations for the CSurface class to use.

Adapter

• SDLDriver::CSurfaceImplSDL, SDLDriver::CEventSDL - These are effectively encapsulations of the procedural SDL API.

Bridge

• CSurface, CScreen - Almost all operations are delegated to methods provided by a private platform-specific implementation object (specifically, a concrete CSurfaceImpl object).

Iterator

• CIterator - Abstract base iterator interface. CDequeForwardIterator and CDequeBackwardIterator are simple concrete iterators that iterate through a STL deque object in the given direction.

Chain of Responsibility

• See the CComponent::handle_event() and CComponent::do_handle_event() methods, as well as the source code for CGame::run().

Template Method

• See the CComponent::handle_event() / CComponent::do_handle_event() and CComponent::draw() / CComponent::do_draw() methods.

Architectural Patterns

Layers

There's a very simple layer heirarchy in this project; the low-level platform/library-specific APIs for events (input), timer functionality, and video are at the bottom layer.

Above them is a layer that exists at a slightly higher level of abstraction, encapsulating the functionality of the low-level APIs and extending them in an extensible ("pluggable") way. This layer is composed of the video subsystem (CVideoSystemManager, CSurface, CColor, etc), the event subsystem (CEventSystemManager, CEvent, etc), and the timer subsystem (CTimerSystemManager). As Mark Shacklette told me, this layer could also be interpreted as a facade design pattern.

Above this layer are the components that use these adapters and bridges: the game application object (CGame), the font module (CFont), the game timer (CFPSTimer), and so forth.

Model-View-Controller

The system uses a rudimentary MVC system that is currently very rough around the edges. See CFPSTimer for an example of a model, and Testing::CFPSGraphicalObserver for a simple example of a view/controller. Also see Testing::CPhysicsTickerModel and Testing::CPhysicsTickerObserver for a more complex (and messy) one.

---