Design Patterns – Template Method Pattern
Gepost op 2008.07.22 | Reacties (6) | C#, Design Patterns, Technologie
Time for yet another pattern, the Template Method Pattern. Have a look at all the other patterns in the series as well.
The definition: “Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm’s structure.“
Let’s add an additional requirement to our game. We need different types of renderers for our GUI, the main screen is in 3D, while the map is displayed in 2D.
Both layouts follow a specific drawing order. First the background, then the units, on screen instructions, special effects and a border. If this order is wrong, it would be possible for the background to overlap the units, which we don’t want.
We’ll start by creating a new base class for our renderers, with some abstract methods which make up the algorithm of drawing the screen.
As you can see, there are two non-abstract methods. DrawBorder() which is common functionality for every render and RenderScreen() which is actually a Template Method.
The Template Method defines the steps used in the algorithm, without actually implementing the steps itself.
As you can see from the comments, with the perfect implementation, RenderScreen() should be a method which can’t be overridden by child classes. C# doesn’t support this however.
When we create our two renderers and have the discipline to not hide RenderScreen(), the class diagram for the Template Method Pattern looks like this:
If we test this code, we notice that the order of rendering a screen is the same, but that each engine implements the steps differently, or not at all.
And that’s the Template Method Pattern! I’ve uploaded the solution again to have a look at.
Also, since I only aggregate technological posts, I’d like to mention this personal post to have a look at: Wanted: Friends!
Some additional information on the Template Method Pattern:
Design Patterns – Facade Pattern
Gepost op 2008.07.20 | Reacties (5) | C#, Design Patterns, Technologie
Time for another, simple, design pattern. The Facade Pattern.
I’m going to need a break soon, getting a bit burned out, which never is a good thing.
Anyway, the definition of today’s pattern: “Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.“
The hardest part of writing articles for this series isn’t so much understanding the patterns itself, but coming up with examples with somewhat make sense in my gaming example. So, please forgive me if they sometimes are a bit far fetched, like today 
Let’s say we have some complex subsystem which handles everything about storage. Some classes for our CD drive, some for our hard disk, memory and much more.
If we need to load a new map, one way to do it would be to load up the cd, copy it to the hd, load it into memory and stop the cd from spinning.
Or, we could also create a new class, which defines some more high-level operations such as LoadMap(), which takes care of dealing with the subsystem.
This way, our clients can use a simple interface, but if they really need to, can still go straight to the subsystem classes themselves, as opposed to the Adapter Pattern, where you only talked to the Adapter.
And that’s it really, Facade and Adapter are very alike, and both very simple.
Let’s have a look at the full diagram, and image the subsystem contains a lot more classes than I drew 
Time to test it and have our client use the StorageFacade directly, instead of the subsystem.
I’ve uploaded the solution again, worth a look.
In my opinion, the Facade Pattern is a helper pattern to make your code easier to use and more user-friendly, other developers being the user.
Some additional information on the Facade Pattern:
Design Patterns – Adapter Pattern
Gepost op 2008.07.17 | Reacties (6) | C#, Design Patterns, Technologie
We’ve seen quite a few patterns so far, and I’m glad so many people like them.
They turned out to be the most popular posts I’ve ever written when it comes to development. Thanks!
A little overview for the late joiners:
- Long Absence – Design Patterns
- Design Patterns – Strategy Pattern
- Design Patterns – Observer Pattern
- Design Patterns – Observer/Event Pattern
- Design Patterns – Decorator Pattern
- Design Patterns – Factory Method Pattern
- Design Patterns – Abstract Factory Pattern
- Design Patterns – Singleton Pattern
- Design Patterns – Generic Singleton Pattern
- Design Patterns – Command Pattern
Today we’ll have a look at the Adapter Pattern.
As usual, the definition: “Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces.“
To continue on our little game, we received a third party library from another team, containing some buildings to include in our game.
The developers of this library didn’t work with IBuildings however, but call it a Structure, making all of our code which interacts with IBuilding unusable.
If we look at the definition, we can see the Adapter Pattern is the perfect solution for this, since we need to convert the interface of the third party Structure into the IBuilding we expect, so that they can work together as if their interface was compatible.
Let’s have a look on how their interface looks like first.
There are some differences in the logic used in their implementation. We both have a Description, but the way we manage Power consumption is totally different.
Time to adapt their interface to the one we expect.
We’ll do this by creating a new class, a so called adapter, which implements the IBuilding interface, since we expect that one, and which uses composition to encapsulate a Structure.
As you can see, our Adapter is actually behaving as an IBuilding to the rest of our code, adapting the calls to our interface into the third party their interface.
And that’s it really! The easiest way I remember this pattern is by thinking of electrical adapters, changing the socket from US to UK, or transforming the voltages.
Time to have a look at the full diagram, with the official names written against it again:
Let’s also write some test code to see the Adapter Pattern in action.
We can re-use all of our existing code with the new Structures, since it’s behaving like an IBuilding right now.
I’ve uploaded the solution again to have a look at.
Feel free to leave any feedback.
Some additional information on the Adapter Pattern:
Design Patterns – Command Pattern
Gepost op 2008.07.16 | Reacties (5) | C#, Design Patterns, Technologie
What’s a lonely geek to do late in the evening? Write about the Command Pattern of course…
Let’s start with the definition: “Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undo-able operations.“
And now, time for the spec I just made up: Our UI has three buttons at the bottom of the screen, which contain various actions. These actions are different depending on the selected item however. We need to implement this piece of UI code, without it having any knowledge of our game units.
How would we approach this? Let’s say these buttons are nothing more than placeholders, to be filled with real buttons whenever a unit is selected. Our game engine will respond to a selected event and create and pass on the real buttons to our UI code.
So, our UI code will only need to know about one thing, a button. Let’s create an interface for this type of button, and coincidentally name it ICommand
We’ll code our UI code against the ICommand, respecting to program against an interface and not an implementation.
At the end, we’ll need some real implementations as well however. So let’s create some “buttons”, which I’ll call Commands from now on.
Right now we only have two types of items, GameUnits and IBuildings. Each Command will perform an action against one of these, encapsulating the object through composition.
For this example, we can make a GameUnit turn Aggressive, Normal and Suicidal. We can also power buildings on and off.
Notice these Commands themselves are written against interfaces as well, our good habits are already starting to pay off.
The NoCommand is a little tricky, it’s just a dummy object, which sometimes is called a Null Object as well. It’s being used for buttons which don’t do anything, basically their default value.
It’s time to create our UI code, the GameControls class. This class will contain the three buttons, ICommands, and helper methods to assign real buttons into the placeholder slots, as well as triggering button clicks.
Additionally, there’s another requirement which has surfaced. We want to be able to undo our last action, whenever possible, can’t undo suicide
We’ll accomplish this by storing the last ICommand, and when an undo action is needed, call the Undo() method on it, since each command provides the exact opposite of Execute() in it’s Undo() method.
That’s all the code that was needed to implement the Command Pattern actually.
Our GameControls class has no idea GameUnit or IBuilding exists, it’s totally decoupled from them.
By using Command objects, we can treat them as little blocks which can be stored in a queue for multiple level undo, we can let several threads pop commands of a queue to process them in parallel, and much more.
Let’s have a look at the full diagram, with the official names written on them as well.
Time to put our code into action and test it.
Let’s imagine we have a full blown engine, and when a unit is selected, various events get fired, resulting in the creation of the correct ICommand objects, being passed to our GameControls UI code, which causes buttons to be displayed on screen. We’ll also simulate a click on the various buttons and the undo button.
That’s it! I’ve uploaded the solution for the Command Pattern so you can have a look at the code of the Command Objects and the details of the GameControls.
Questions? Feedback? Comment!!
Some additional information on the Command pattern:
