Interesting that you use MVC as your example. Did you know the original Gang of Four (GoF) had an entire section in their book explaining why MVC is not a pattern, but a design? The original design patterns were supposed to be much more abstract than MVC – they described structures and interactions at a very broad level, trying very hard to avoid prescribing how those structures and interactions manifested themselves.
Let’s take a for-instance: within MVC, a model may have several different views. Each of these views needs to be notified when the underlying model changes. Think about the interaction: multiple objects want to receive a notification when something else changes without requiring that underlying object to explicitly hold a reference to them. This happens a lot – not just in MVC, and it was described by the GoF as the Observer pattern.
MVC has plenty of other examples… A view might be made up of other, smaller views, an example of the Composite pattern; A view might need to be modified in some way at runtime, such as get disabled, it can be done using a DisabledView wrapper, an example of the Decorator pattern; MVC might want to change the way it reacts to input based on the state of the system, it can do this by swapping out the active controller, an example of the Strategy pattern; A model might want to remember its state and the corresponding commands that caused it to change so that it can be reverted to a previous state, an example of the Memento and Command patterns…
You see, the design patterns are all around us, we simply may have not noticed them before we named them.
You say
But I find that very unlikely. Indeed, just yesterday I was explaining that by the time I had enough experience to really wrap my head around design patterns, I discovered I had already been using them. This leads to a, perhaps, disturbing implication: design patterns will not magically transform you into a programming master. In my own experience, recognizing them has led to two primary benefits:
- I can communicate abstract ideas about how code might be structured to solve a problem
- I can quickly come up with alternative solutions and possible implementations based on my knowledge of how the patterns are related
So, let’s talk about some of the design patterns you might see in Unity.
Composite is an obvious one right? Actually, I think there is some confusion here. The Composite pattern is described as “a container which provides the same interface as the components it contains”. It’s purpose is to reduce the difficulty of dealing with possibly zero, one or many references into dealing with always, just one. This is not really what the component system of Unity provides. There is a trap here because “composition” looks, sounds, and, to many, means something very similar to “composite”. That doesn’t mean it doesn’t apply to Unity though. The composite pattern is very useful for building up complex objects. I wrote up two lengthy posts which talk about how the Composite pattern, Decorator pattern and AbstractFactory patterns could be used to create things as different as complex weather effects and customizable abilities with a large number of modifier effects.
A pattern that is often missed, but I believe is a core concept in Unity, is the Prototype pattern. The Prototype pattern is described as “a fully initialized instance to be copied or cloned”. This pattern can simplify the creation of objects that either you need many identical, or slightly different copies of. Sound familiar? You can see it in the prefab system of Unity.
Have you ever used an object pool to reduce memory load in your game? This is an example of the flyweight pattern; the mesh, textures and logic of the pooled objects can be thought of as intrinsic data while the settings which control how that object will behave once you take one from the pool is the extrinsic data.
The Message System in Unity look very similar to the Observer and Command patterns to me, and probably use many other patterns under the hood.
The WWW class is just one example of the Façade design pattern, and I’m sure you can find this guy everywhere once you understand what it is describing.
Another member, @JoeStrout , recently created an in-game scripting language called MiniScript and followed up with a cool mini, meta programming game. I don’t have any evidence to support this, but there’s a good chance he used (or could have used) the Interpreter design pattern in his implementation.
Singleton gets a lot of attention on the forums because it is such a simple way to share common game components across your game. I would be very surprised if you’ve never used this design pattern, intentionally or not.
Though I have no experience doing so, nor links to explain how, I think the Builder pattern would be very useful for dynamically creating a complex physical structure such as a maze or building.
Hopefully I’ve convinced you design patterns proliferate our code more than you thought. The question is how can we use that knowledge to improve our programming? Some people believe patterns are bad because they obscure real problems or encourage over-engineering, but I think there is some faulty logic and personal bias at work here. This is like blaming weapons for killing.
I’m all out of time but maybe this is at least a little helpful for your assignment. If nothing else, it might give insight into what patterns actually are and do.