Week 3: Design Patterns

This week our class focused on design patterns that are commonly used in software design. We covered the factory, facade, state and singleton patterns. 

Factory Pattern

The factory pattern is basically the idea that you have one place where you can create your objects. All it requires is for you to pass in an ID indicating which object you'd like created and the factory will create it for you. This design pattern is especially useful in terms of implementing support for scripting. As opposed to having a user explicitly instantiate objects, we would simply have them call the factory and ask for the factory to create the object for them. This simplifies the process for the user of the script, as they don't have to worry about what is going on in the background. This also gives control to the engine programmers as they determine how objects will be instantiated through the factory.

Facade Pattern

The facade design pattern simply involves taking a collection of related classes and giving them a single interface to communicate with a the interface of a different system. If we think of our code as a store, and objects as employees, these would be the managers of a specific department. Managers of different departments communicate information about their own individual apartments to each other and/or to their managers. 

This also keeps each major component of a framework independent of another. If your graphics and physics systems must communicate but are tied together, then you won't be able to change one without affecting the other. Using the facade design pattern we would have them communicate from a single interface, and if say we wanted to update the physics system because it was poorly designed on the first pass, then we would only change that system. This design pattern keeps communication between systems clean, avoiding the messy practice of unnecessary interdependent systems.

State Pattern

Having used states in the past, and experiencing first hand the nightmare of maintaining all those states, I can only thank the software design gods for revealing this design pattern to humanity.

Thank you Software God for revealing these design patterns to us.
And ye

This design pattern involves creating a state manager that handles the logic and switching of states in an object. The use of a manager also allows the code to be shared between functions since it is not hard coded into a single class. This design pattern makes state hadnling a much more managable, clearer and cleaner process.

Singleton Pattern

The singleton pattern basically limits the instantiation of a class to one object. Put simply, you would use the singleton pattern in situations where you only need one of that specific object. Some examples given in class included only requiring one renderer or one mouse. This is implemented through a class that contains a static data member, and all instantiations of that class point to the same place in memory. 

The most obvious example of where this design pattern should be used is in something like a Game class, where your main game loops are; you don't want to open multiple instances of a game at the same time! Although I've never heard of anyone doing this, I'm sure it has somehow happened before. Any manager of a system or subsystem should also be a singleton. The idea is to have just one.

This design pattern is one that I've actually used before. Although I didn't really use it for the important things, like renderers, physics managers, animation managers and the like - I used it for storing mesh information and texture information.

Our second year game, a bullet hell shooter titled The Next Dimension, had to render several enemies on screen at once. Initially, we had set up our classes such that each enemy object stored all the information necessary to render it, which was really just a mesh and a texture. The problem with this was that we were storing the same texture and mesh information, about 100 times. When we realized this, it was a simple solution really; all we had to do was make sure that the texture and mesh were shared across all instances of the objects such that they could be accessed and drawn 100 times, whilst only having to store it once.

Singletons mostly seem there to protect the dynamic loading of objects in code, as you never know who might try to instantiate more than one instance of an object.