Real World – Liskov Substitution Principle

liskov-substitutionsolid

Background: I am developing a messaging framework. This framework will allow:

sending of messages over a service bus
subscribing to queues on the message bus
subscribing to topics on a message bus

We are currently using RabbitMQ, but I know we will be moving to Microsoft Service Bus (on Premise) in the very near future.

I plan to create a set of interfaces and implementations so that when we move to ServiceBus, I simply need to provide a new implementation without amending any of the client code (i.e. publishers or subscribers).

The issue here is that RabbitMQ and ServiceBus are not directly translatable. For example, RabbitMQ relies on Exchanges and Topic Names, whereas ServiceBus is all about Namespaces and Queues. Also, there are no common interfaces between the ServiceBus client and the RabbitMQ client (e.g. both may have an IConnection, but the interface is different – not from a common namespace).

So to my point, I can create an interface as follows:

public interface IMessageReceiver{
  void AddSubscription(ISubscription subscriptionDetails)
}

Due to the non-translatable properties of the two technologies, the ServiceBus and RabbitMQ implementations of above interface have different requirements. So my RabbitMq implemetation of IMessageReceiver may look like this:

public void AddSubscription(ISubscription subscriptionDetails){
  if(!subscriptionDetails is RabbitMqSubscriptionDetails){
    // I have a problem!
  }
}

To me, the line above breaks Liskov's rule of substitutability.

I considered flipping this around, so that a Subscription accepts a IMessageConnection, but again the RabbitMq Subscription would require specific properties of a RabbitMQMessageConnection.

So, my questions are:

Am I correct that this breaks LSP?
Do we agree that in some cases it is unavoidable, or, am I missing something?

Hopefully, this is clear and on topic!

Best Answer

Yes, it does break the LSP, because you are narrowing the scope of the sub-class by limiting the number of accepted values, you are strenghtening the pre-conditions. The parent specifies it accepts ISubscription but the child does not.

Whether it's unavoidable is a thing for discussion. Could you maybe completely change your design to avoid this scenario, maybe flip the relationship around by pushing stuff into your producers? That way you replace the services declared as interfaces accepting data structures and the implementations decide what they want to do with them.

Other option is to let the user of the API explicitly know, that a situation of an unacceptable sub type might occur, by annotating the interface with an exception that might be thrown, such as UnsupportedSubscriptionException. Doing that you define the strict pre-condition right during modeling of the initial interface and are allowed to weaken it by not throwing the exception should the type be correct without affecting the rest of the application which accounts for the error.

Related Solutions

Design Principles – Violation of the Liskov Substitution Principle?

Yes, it is a violation of the LSP. Liskov Substitution Principle requires that

Preconditions cannot be strengthened in a subtype.
Postconditions cannot be weakened in a subtype.
Invariants of the supertype must be preserved in a subtype.
History constraint (the "history rule"). Objects are regarded as being modifiable only through their methods (encapsulation). Since subtypes may introduce methods that are not present in the supertype, the introduction of these methods may allow state changes in the subtype that are not permissible in the supertype. The history constraint prohibits this.

Your example breaks the first requirement by strengthening a precondition for calling the Close() method.

You can fix it by bringing the strengthened pre-condition to the top level of the inheritance hierarchy:

public class Task {
    public Status Status { get; set; }
    public virtual bool CanClose() {
        return true;
    }
    public virtual void Close() {
        Status = Status.Closed;
    }
}

By stipulating that a call of Close() is valid only in the state when CanClose() returns true you make the pre-condition apply to the Task as well as to the ProjectTask, fixing the LSP violation:

public class ProjectTask : Task {
    public override bool CanClose() {
        return Status != Status.Started;
    }
    public override void Close() {
        if (Status == Status.Started) 
            throw new Exception("Cannot close a started Project Task");
        base.Close();
    }
}

Liskov substitution principle with abstract parent class

You can answer questions like this by going back to first principles and asking "what is the Liskov substitution principle intended to accomplish?" And the answer to that is that code that works correctly with the superclass should also work correctly with all subclasses. (For CS theory purposes there is a more specific mathematical definition but for the workaday programmer that's likely to only be concern if you are creating a programming language).

So, why would an abstract class be easier? There really is no situation where using a concrete class means you can't possibly follow the Liskov substitution principle in your subclasses. After all, the superclass defines a contract for the subclasses either way. The fact that it also contains one possible implementation of the contract is neither here nor there.

However, one might make the argument that psychologically it's easier to focus on a contract when making an abstract class, and perhaps a concrete class might take an implementation detail and accidentally make that part of the contract. It seems sort of plausible without being really convincing.

As far as never using a concrete class - perhaps a good rule of thumb is to be a bit skeptical of any design philosophy that says you should never use a standard, not totally broken feature of a language. In this case, the chance that you might, maybe, be more likely to make a mistake designing the contract of a concrete class vs. an abstract one - well that would be at best a minor factor in making that decision.

Best Answer

Related Solutions

Design Principles – Violation of the Liskov Substitution Principle?

Liskov substitution principle with abstract parent class

Related Topic