SOLID principles are a set of guidelines for designing and writing software that is easy to maintain, extend, and reuse. One of these principles is the interface segregation principle (ISP), which states that clients should not depend on interfaces that they do not use. In this article, we will look at some examples of how to apply ISP in different programming scenarios.
An interface is a contract that defines the methods, properties, and events that a class or a structure can implement. Interfaces allow for abstraction and polymorphism, which means that different types can behave in a consistent way without knowing the details of their implementation. For example, an interface called IAnimal can declare a method called MakeSound, and any class that implements IAnimal can provide its own version of MakeSound.
Using "animals" when talking about programming is over-used and actually is quite confusing for those that don't know the topics already. A real animal has too many traits, and having an animal just with MakeSound is just plain weird. I would say that the basic example that makes much more sense is an ILogger, where one implementation can log to the console, another one can log to a file, another one to a database etc. That way, we are talking about something that actually works, and not just throwing in a random interface that would probably never be used in a real application.
A better analogy might be a Steering Wheel. It's an interface that allows a person to honk the horn and steer the car without having to know how the car manufacturer implemented the car. In fact, a Wheel can be used to steer things that aren't cars, such as trucks or planes or boats.
Just a small issue, the article says that "clients should not depend on interfaces they do not use"... but it is more than that, as the real point is to avoid having interfaces with lots of methods they would never use.
The main reason to segregate interfaces is to avoid coupling and complexity. Coupling is the degree of interdependence between software components, and complexity is the difficulty of understanding and modifying the software. If an interface has too many methods or properties that are not relevant to some of its clients, then those clients are forced to depend on things that they do not need or use. This can lead to unnecessary code, bugs, and difficulties in testing and changing the software.
One way to segregate interfaces is to follow the single responsibility principle (SRP), which states that a class or an interface should have only one reason to change. This means that each interface should have a clear and specific purpose, and should not contain methods or properties that belong to another interface. For example, instead of having a single interface called IShape that defines methods for drawing, resizing, and rotating shapes, we can have three separate interfaces: IDrawable, IResizable, and IRotatable.
SRP is a great way to keep code readable, maintainable and testable. Just reading the methods prototype you get a glance of the “what and how”.
Suppose we have an online store that accepts different payment methods, such as credit card, PayPal, and Bitcoin. We can define an interface called IPaymentMethod that declares a method called Pay, and have different classes that implement this interface, such as CreditCard, PayPal, and Bitcoin. However, not all payment methods have the same attributes or behaviors. For example, credit cards have a card number, an expiration date, and a security code, while PayPal and Bitcoin have an email address and a password. Also, credit cards and PayPal can be refunded, while Bitcoin cannot. Therefore, it makes sense to segregate the IPaymentMethod interface into smaller interfaces, such as ICardPayment, IOnlinePayment, and IRefundable.
I actually see a problem with the IRefundable. The same way a credit card requires more arguments in its Pay() method, it will probably require more arguments to issue a refund. The way I see it, the class implementing the IPaymentMethod should be instantiated with all the card info, so the Pay() method only needs to receive the amount as argument. This would allow to use a single signature that works for CreditCard, PayPal and Bitcoin. Also, maybe the return of Pay() could be an optional IRefundable, so if that particular transaction or payment method can't be refunded, a null result or similar will tell that.
Suppose we have a database that stores information about customers, products, and orders. We can define an interface called IDatabase that declares methods for connecting, disconnecting, querying, and updating the database. However, not all clients of the IDatabase interface need to perform all these operations. For example, a client that only reads data from the database does not need to update it, and a client that only updates data does not need to query it. Therefore, it makes sense to segregate the IDatabase interface into smaller interfaces, such as IConnectable, IDisconnectable, IQueryable, and IUpdatable.
IConnectable and IDisconnectable are actually an example of a bad pattern. First, if the object can be opened and closed, it will always implement both interfaces. Yet, it is probably better to have an IConnector with a Connect method that will return a connected IConnection... then, when such object is deleted/disposed it closes the connection.
Suppose we have a file system that supports different types of files, such as text, image, and audio. We can define an interface called IFile that declares methods for opening, closing, reading, and writing files. However, not all types of files have the same capabilities or formats. For example, text files can be encoded in different ways, image files can have different resolutions and colors, and audio files can have different bitrates and frequencies. Therefore, it makes sense to segregate the IFile interface into smaller interfaces, such as IOpenable, IClosable, IReadable, IWritable, IEncodable, IResolvable, and IAudioable.
Is an IOpenable and IClosable really a good idea? Will we ever want an object that can only be opened but never closed? As there is no more explanation of the interfaces, I assume the object will come in closed state, and we might want to Open() it... and later Close() that object. So, having such segregation of interfaces becomes a bad practice.