Getting Rid of the Case Statement From Hell

In most commercial applications that I have worked with, I have found a curious pattern that continues to emerge – the Case Statement From Hell pattern.  This pattern can be found in any language which has a switch/case, select/case or other form of case statement and is often found in a method which is handling GUI code.  The Case Statement From Hell usually emerges in an event handler which has to process parameters.  These parameters may be in the form of an enum, but in most cases are usually strings.  The Case Statement From Hell has a variable length, but can quite often stretch for thousands of lines of code, violating the “avoid writing long methods” principle of good object oriented design.

If you have seen the Case Statement From Hell pattern, you know what I mean.  If you have not seen the Case Statement From Hell pattern then either you aren’t a developer, or you are a developer and I really, really want to work where you’re working.  Nevertheless, these giant case statements can usually be re-factored easily enough.  They key to doing so is to think a little bit about what the case statement is trying to accomplish. Continue reading

Favor Composition Over Inheritance part 2

Yesterday I wrote part one of my two part series on why we should favor the technique of composition over inheritance. I began by looking at how a purely inheritance-based model quickly becomes unworkable as the properties and methods of base classes often lead to an inflexible design. Today, by contrast, I will look at solving the same problem by the use of composition. Specifically, we will look at how using interfaces for composition in C# allows for a highly flexible design.

The problem posed yesterday was to model the behavior of a car when a driver applies changes to it. I want to be able to track the angle of the wheels and the speed at which the wheels have been turned by the engine. The first car to model is the Toyota Corolla. Continue reading

Favor Composition Over Inheritance part 1

“Favor composition over inheritance” is a phrase that I hear spoken a lot but which describes a concept I rarely actually see in real world code.  Every developer seems to know about it but few developers seem to actually put it into practice. This post will be looking at inheritance and some of the pitfalls of trying to create your domain model primarily through inheritance.

I can only assume that the reason why inheritance is so overused in real world code is due to the way that it is taught.  Back, far too many years ago, while I was still studying at university, the concepts of inheritance and polymorphism where both taught side by side, very early in the object oriented programming course.  It seems as though these lessons were particularly memorable, because so much real-world code has giant inheritance chains.  We have ObscuredItems inheriting from DataItems inheriting from BasicItems which inherit from Items which inherit from BaseObjects.  Often times you will have to go five or six classes deep to find the root cause of a bug.

Favoring composition over inheritance helps us flatten those structures.  To illustrate this, I am going to take a look at a very simple problem. Continue reading