This blog post is an adaptation of an answer I posted to Programmers.Stack Exchange. You can find the original post here.
The Liskov Substitution Principle is one of the five major OO design principles described by the SOLID acronym. Quite simply, it says that when we design our class hierarchy, child objects should behave like their parent objects.
An easy way to conceptualise the LSP is to imagine a scenario where the LSP is violated. Consider the following:
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
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” 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
Every new blog has a first post. Every first post is awkward.
This blog is basically for me to detail my thoughts about coding. I’m a professional coder who has been programming both professionally and for fun for the last twenty years (since I was 10 years old). I’m always learning something new and this blog is about what I’m learning or have learned.
My current language of choice is C#, so that’s what you’ll mostly see on this blog. However, I am open to learning other languages and may occasionally post my thoughts about them here too. I am far more interested in concepts and algorithms than I am in language semantics, which makes C# a great choice for this blog. The advantage of C# is that it does not have too many “gotchas”, that is, things which behave in strange ways. C++ is a well known example of a language that has all sorts of language quirks that requires specific knowledge to avoid. C# by contrast is much more about choosing the right way to solve the problem, which is what I’m interested in.
I would love to hear feedback, so drop me a line and let me know your thoughts.
Coding Delight 