Object composition and design patterns.

I just finished reading the book Head First Design Patterns which is a really nice read. Even though the content is java oriented, pretty much anyone should be able to take the concepts and patterns explained and apply them in their own language.

So you might ask yourself "what the hell are design patterns and why would I want to know them?".

Design patterns are a way to look at problems and look at solutions and see if there isnt some way to abstract the way you approach a solution so that it applies consistantly to a class of problems.

If you think of it as a way of thinking about design at a higher level, its a good start.

The reason why it interests me, is that I've long been a big advocate of certain ways of architecting game code. Now I've got a name for this architecture! Not only that, but it appears other people think the same way, enough so that they've taken the time to give what I advocate a name and can give examples of how it should be used.

Just out of interest, the most important aspects that I've advocated.

The observer pattern (for decoupling objects)

You use the observer pattern where you want multiple objects to be aware of another objects state, but decoupled from the actual object being observed. The reason I advocate this, is that It helps keep compile times down, but also because it helps modularity, to loosely couple systems via some indirection, means that you can replace subsystems and keep the client (observer) unaltered.


The strategy pattern (erm, I think its that one, I'll have to go look again),

This is where you create object behaviour via composition rather than inheritance. By moving behavior into different classes and having objects incorporate them at runtime, you achieve a level of modularity in behavior and get rid of the problem of inheritance. Essentially, you isolate behavior into seperate classes and then get objects to exhibit that behavior by "composing" objects with those classes. This becomes a huge advantage when you want lots of objects (lets say weapons), but dont want to write thousands of classes, each mostly the same, but with minor tweaks.

These are the two I really am interested in. I'm sure I'll think of more as I go on learning about patterns. But these two I've used out in the wild and really appreciate.

So what has this got to do with the price of beans?

Well, I'm right now working on some little projects while my PC is offline at home. These projects are being prototyped using Torque Game Builder. But not just stock TGB. This is TGB with "behaviors", behaviors being, well, pretty much the behavioral composition pattern I talked about from the strategy pattern!

So, soon enough I should be able to post a blog with some demo's that show you how that actually works. I'm working on a series of video's showing some "rapid game prototype" developments. Only need a few bugfixes and we should be good to go.

Hope you get interested in design patterns, they arent just for coding and can be used in many different areas, for things like business processes etc. Hell, I guess they could be used for personal relationships too.

.Zoom.