The Liskov Substitution Principle

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:

Continue reading

Advertisements

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