SOLID Principles for Game Developers

SOLID Principles

 The SOLID principles are a set of 5 software development principles coined by “Uncle Bob” (Robert C. Martin). They are a set of guidelines for Object Oriented Design (OOD), specifically for class design. They are widely used by agile business programmers however they are generally unknown amongst game developers. This article describes the principles and frames them in common game development situations.

Single Responsibility Principle

“There should never be more than one reason for a class to change.”

Single Responsibility Principle

The first principle is the cornerstone of the set and gives the greatest return on investment when followed correctly. It states that each class should have only a single responsibility and therefore reason to change. Keeping each class small and tightly focussed allows developers to know exactly where to go to find or add particular functionality to the game.

Why is having more than one responsibility bad? Multiple responsibilities means there is coupling between separate pieces of code. Changes to one responsibility reduce the ability for the class to meet the requirements of the other responsibilities. This leads to fragile design that breaks often and in unexpected ways. “Why did changing from rendering API break jumping in the game?”

The way to fix code that breaks this principle is to separate each responsibility into its own class. The first step can be to extract an interface per responsibility. Other classes can then rely on these interfaces rather than the class itself. The class can then safely be split up into separate classes for each responsibility that each implements a single interface.

When have you got it? – The usual culprit breaking this principle is that one (or group) class that’s hundreds or thousands of lines long. You know the one I’m talking about. Often it’s the GameObject or Entity class that everyone seems to throw code into. This class usually has about 500 reasons to change, and therefore 500 responsibilities. It’s usually involved in the heinous bugs that crop up constantly.

Open Closed Principle

“Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.”

Open Closed Principle

This principle can easily be resolved with data driven design. By passing the required configuration data to a class it can easily be extended reducing its need for modification. Any variables (in the mathematical sense) should be passed to the class so that the classes definition itself (the code) does not specify the functionality of the class alone. I find this the easiest to think about in terms of the basic OOD principle of data and operations. The class defines the operations it can perform (its functions) and the data that it operates on. As much of this data as possible should be passed to the class/function. This moves the configuration of its data outside the class itself to the calling code increasing its ability to change.

When have you got it? – This is the file you dread checking-in because everyone seems to be working on it all the time. No matter what system you’re working on, these files always seem to be involved.

Liskov Substitution Principle

“Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.”

Liskov Substitution Principle

The first step is formalising these conditions into code. Once this step is completed the following rule can be met – “Derived classes can only weaken pre-conditions and strengthen post-conditions”. Put another way, functions of a derived class should expect no more than their base class and promise no less. This principle is important because of the fact a model viewed in isolation cannot be meaningfully validated. You don’t know whether your new “Tank” class is valid until you run it in the context of its parent, siblings and other game system.

When have you got it? – Classes breaking this rule are really easy to find. Look for any base class that uses run-time type information (RTTI) to interrogate its own type (or the type of an object it’s working on). As soon as the GameEntity class is checking if it’s of type “Tank” to do some special code, you’ve broken this principle. The class should be able to polymorphically call functions without caring about the actual type of the object.

Interface Segregation Principle

“Clients should not be forced to depend upon interfaces that they do not use.”

Interface Segregation Principle

This principle links back to the single responsibility principle nicely. In this case each interface should have a single responsibility. This lets you explicitly state the functionality requirements of each object based on the interfaces it requires.

When have you got it? – Look at all your interfaces (abstract classes) and make sure their listing of functions are homogenous. An easy way to tell you’ve broken this principle is when there are small groupings of functions within the interface definition. Whitespace is the key here, the more whitespace between the groups of functions, the more disparate they are.

Dependency Inversion Principle

“High level modules should not depend upon low level modules. Both should depend upon abstractions.” “Abstractions should not depend upon details. Details should depend upon abstractions.”

Dependency Inversion Principle

A good example of this is in a rendering system. Rather than instantiating a rendering object, or directly calling the classes of the rendering API, the rendering system should receive an interface to the low level rendering functionality. By relying on an interface that is given to the rendering system, the low level rendering API can be changed without making breaking changes to the client rendering system. It becomes obvious if breaking changes occur as the low level rendering API’s interface will require changing.

When have you got it? – When two systems are talking to each other, how do they do it? If they are using concrete classes then look for opportunities for them to rely on interfaces instead. The best way is for the class to take as parameter to its constructor an interface reference to the class it needs to work on. This also makes it obvious what sub-systems are particular class is reliant on.

Conclusion

What are your thoughts on the SOLID principles? Do you see benefit from adopting these in the games industry as web and application development has done?

P.S. My latest game, Flick Buddies, is free today as part of Open Feint's Free Game of the Day, grab it here.

SOLID Motivational Posters, by Derick Bailey