In Snowball I was debating adding an empty interface to identify certain classes in my framework as components. I wasn’t sure if this was code smell or not so I did some searching on Stackoverflow and found out this concept is actually called “Marker Interfaces”. Learn something new every day.
I moved the ComponentGlue repository to GitHub. I updated the example slightly and cleaned up some of the source code a little. Need to build a full blown app with it eventually.
You may have heard the expression before “Favor Composition over Inheritance”, but do you know what it means and how to apply it? Lets take this code for example:
abstract class Car
{
public Color Color { get; protected set; }
public Engine Engine { get; protected set; }
}
class ElectricCar : Car
{
public ElectricCar()
{
this.Color = Color.Blue;
this.Engine = new ElectricEngine();
}
}
class SportsCar : Car
{
public SportsCar()
{
this.Color = Color.Red;
this.Engine = new V8Engine();
}
}
class Truck : Car
{
public Truck()
{
this.Color = Color.White;
this.Engine = new DieselEngine();
}
}
In this contrived example, we’ve defined three types of cars. Each instance of each of the cars will always have the same color and same engine. What happens when we need a 4th type? We have to define another class. By refactoring this code, we can compose a car type by giving it a color and an engine:
class Car
{
public Color Color { get; private set; }
public Engine Engine { get; private set; }
public Car(Color color, Engine engine)
{
this.Color = color;
this.Engine = engine;
}
}
Car electricCar = new Car(Color.Blue, new ElectricEngine());
Car sportsCar = new Car(Color.Red, new V8Engine());
Car truck = new Car(Color.White, new DieselEngine());
Car familyCar = new Car(Color.Black, new V4Engine());
Now we can compose many car types, with any combination of colors and engines and we’ve only defined one class.
The other day I started an open source project for an IoC Container I call Component Glue. It’s in a toy / learning tool status right now and I don’t know how far I actually want to take the project. More to come though.
I was reading the Scientific Ninja Blog this morning and he has posted a link to an in progress site / book by Robert Nystrom about game programming patterns. It’s not complete yet but it’s quite an interesting read to say the least.
By extending your Service Container class, a very basic version of dependency injection can be implemented. We’ll implement two forms of dependency injection: constructor and property injection.
I recently became interested in doing MVC inside of a Windows Forms app. I found a few MVC frameworks which work with WinForms (see here) but they didn’t really interest me. Too heavy I felt for what I was looking to do. I ended up with a solution looking something like this:
There is really only one controller and that is the “Application” class. It contains all the methods your app can call to manipulate your models, which are in the “Data” folder / namespace. The “WinFormsApplication” class inherits from the “Application” class and just sets the view to an instance of “WinFormsView”. The “Application” class communicates with the view through the “IView” interface. The “WinFormsView” class is a Windows Forms implementation of that view. The “Application” class and your models are not coupled in any way to your Windows Forms implementation of the view.
If you want you view to be as dumb as possible, your view can communicate with the “Application” class only through events. In my case though, I choose to go with a smart view and have the view call back to methods in the “Application” class. The “Application” class tells the view when models are loaded and unloaded. The view subscribes to events on the models and reacts to the events.
All of my forms and controls communicate with each other through the “WinFormsView” class. One control might change the value of a property in the “WinFormsView” class and another control might subscribe to a change event and update as necessary. This keeps the controls and forms slightly less coupled.
It’s not a perfect implementation of MVC but it keeps my model logic decoupled enough from my view logic that I can later implement a WPF version of the view I think.
The GameServiceContainer implements the IServiceProvider interface and the MSDN documentation says about the IServiceProvider interface:
Defines a mechanism for retrieving a service object; that is, an object that provides custom support to other objects.
This article will “attempt” to describe how can you use the GameServiceContainer in your XNA game, in both your GameComponent(s) and your game’s entity objects.
Continue reading