Understanding Liskov Substitution Principle

The Liskov Substitution Principle, in its simplified, object oriented language way, says that:

Derived classes must be substitutable for their base classes.

The principle looks simple and obvious; at first look we are tempted to question that the opposite is true: can one make a class that is not substitutable for their base class? Technically speaking no. If one makes a derived class and the compiler does not complain everything should be fine. Or is it not?

Let’s see a simple example:

public class MusicPlayer {
    public virtual void Play(string fileName) {
        // reference implementation for playing
    }
}

// Optimized mp4 player
public class Mp4MusicPlayer : MusicPlayer {
    public override void Play(string fileName) {
        if (Path.GetExtension(fileName) != "mp4")
            throw new ArgumentException("can only play mp4");
        // optimized implementation for playing
    }
}

In the above example we have a reference implementation for a music player. The reference implementation would play all types of files but maybe not with the best performance or quality. An optimized player for a certain type of file, for example for a MP4 file type, is as far as the c# interface is concerned a specialized type of music player.

So what’s the problem? The above Mp4MusicPlayer class just violated the Liskov substitution principle. One cannot substitute MusicPlayer with Mp4MusicPlayer bacause the later works only with certain specific music files. Where MusicPlayer would work with a MP3 file, the Mp4MusicPlayer would throw an exception and the program will fail.

Where did this go wrong? As it seems, there is more to an interface that meets the eye. In our case the preconditions of the derived class are stronger than those of the base class and even if in c# the interface does not contain in it’s definition the preconditions you will have to keep them in mind when designing the inheritance tree.

But there is more than that. The above is only one way in which the Liskov substitution principle can be violated. In a more general terms is a problem of abstractions. When one defines a base class or an interface it actually defines an abstraction. And when one makes a derived class implicitly agrees to satisfy the same abstraction.

In the example above the MusicPlayer abstraction is “something that can play any music file”
But Mp4MusicPlayer abstraction is “something that can play MP4 music files”

The abstractions are different, and this is the root cause of the problem. When the abstractions are not appropriate the situation can get nasty.

Liskov substitution principle is all about abstractions

There are multiple ways in which the abstraction can be broken. A wrong abstraction can be hacked in simple cases but eventually it will come back to byte you. We might be able to install an electronic device on the wooden horse in the right of the above image if we need the “horse” abstraction to neigh but we will never persuade it to eat a hand of hay.

Implementing a Simple Generic Repository with LinqToSql

The Repository pattern

The Repository is a design pattern often used in Domain Driven Design (DDD) to help the domain layer access data needed from the underlying persistence layer.

The Repository pattern was described by Martin Fowler as:

A Repository mediates between the domain and data mapping layers, acting like an in-memory domain object collection. Client objects construct query specifications decoratively and submit them to Repository for satisfaction. Objects can be added to and removed from the Repository, as they can from a simple collection of objects, and the mapping code encapsulated by the Repository will carry out the appropriate operations behind the scenes. Conceptually, a Repository encapsulates the set of objects persisted in a data store and the operations performed over them, providing a more object-oriented view of the persistence layer.

In DDD the repository is tightly linked with the aggregate notion. The aggregate is a hierarchy of objects that are treated as a unit for the purpose of data changes. The aggregate components are accessed only from its root object. A repository is usually build around an aggregate.

As an example we may have a Car aggregate that has a collection of Wheels.

In our domain we will never refer to a wheel directly but first get a car and have access to its wheels.

Most of the time we need just a couple of operations to deal with aggregates on the repository.  With the above example we would have to implement in the repository methods to:

• Add a new Car
• Remove a Car
• Get the Car by Id
• Get a filtered list of Cars

Implementing this in LinqToSql is pretty straightforward but it has its catches.

Add and Remove

The simplest to implement are the add and remove methods:

    public class Repository<T> where T : class {
        CarsDataContext _dataContext = new CarsDataContext();
        public void Add(T entity) {
            DataContext.GetTable<T>().InsertOnSubmit(entity);
            DataContext.SubmitChanges();
        }
        public void Remove(T entity) {
            DataContext.GetTable<T>().DeleteOnSubmit(entity);
            DataContext.SubmitChanges();
        }
    }

Nothing special here. The generic GetTable of the LinqToSQL data context is used to insert/delete the entity and then SubmitChanges is called to send the changes to the database. The methods can be used like this:

    Repository<Car> carRepository = new Repository<Car>();

    // create a new car and add it
    Car newCar = new Car();
    carRepository.Add(newCar);

    // get an existingCar, then remove it
    Car existingCar = ...
    carRepository.Remove(existingCar);

Get By Id

Implementing the get by id method is a little more challenging. The first thing is to ensure that the model has the ‘Id’ notion. By default the LinqToSql classes do not have a direct way of exposing an identifier meta-data. We can have this by adding an interface and ensure the classes implements it:

    public interface IIdentifiable {
        int Id { get; }
    }
    public partial class Car : IIdentifiable {
    }

All the classes that need to be get by Id will have to implement the IIdentifiable interface. This is done in the code above by adding a partial class that implements the IIdentifiable interface. There is a catch here. If a consistent naming convention is used and all the classes have an ‘Id’ property then the above code is all we need.

With the classes prepared we can then write:

    public class Repository<T> where T : class, IIdentifiable {
        public T GetById(int id) {
            T entity = DataContext.GetTable<T>().SingleOrDefault(e => e.Id.Equals(id));
            return entity;
        }
    }

Please note the e.Id.Equals(id) above. LinqToSql does not know how to generate the == operator when interfaces are involved but it knows to generate the proper expression tree with Equals.

The GetById method can then be used like:

    Repository<Car> carRepository = new Repository<Car>();
    Car existingCar = carRepository.GetById(1);

The generated SQL contains what we expect, a parametrized query:

    exec sp_executesql N'SELECT [t0].[Id], [t0].[Make], [t0].[Year]
    FROM [dbo].[Car] AS [t0]
    WHERE [t0].[Id] = @p0',N'@p0 int',@p0=1

Getting Aggregate Elements

As LinqToSql supports lazy loading so all is needed is to access the elements from the root.

    Car car = carRepository.GetById(1);
    Console.WriteLine(car.Make);
    Console.WriteLine(car.Wheels.Count); // additional query will hit the database

Clean and easy. For more complex scenarios where one would need to control the loading behavior the DataLoadOptions of the LinqToSql can be used.

Get a Filtered List

The simplest to implement this is to allow expression filters as parameters:

    public IQueryable<T> GetByFilter(Expression<Func<T, bool>> filter) {
        return DataContext.GetTable<T>().Where(filter);
    }
    // and this can be used like:
    IQueryable<Car> cars = carRepository.GetByFilter(e => e.Year == 2009 && e.Make == "Ford");

An IQueryable is returned to allow simple UI integration. For example using a GridView with a LinqToSql source will automatically have sorting and paging implemented with this approach. The downside of this approach is that the DataContext will remain open up to the UI layer and this might introduce performance penalties. The alternative would be to return an IEnumerable instead and let the UI handle the pagination and sorting.

Conclusion

The solution presented is not without flaws. The biggest one is the tight link between the DB implementation and the model, forced by the LinqToSql architecture. There is also the inconvenient of having all primary keys named ‘Id’ and having to write partial classes for implementing the IIdentifiable interface. But there are also a couple of nice things like a very simple and clean usage, the possibility to use generics with aggregates and, maybe the best one, the possibility of avoiding boiler plate code.

Download the supporting code for this article (12.0 KB).