As per the Interface Segregation Principle
clients should not be forced to implement the unwanted methods of an interface
...and so we should define interfaces to have logical separation.
But default methods introduced in Java 8 have provided the flexibility to implement methods in Java interfaces. It seems Java 8 has provided the feasibility to enhance an interface to have some methods not related to its core logic, but with some default or empty implementation.
Does it not violate the ISP?
Good question. Definitely, it violates Interface Segregation Principle and I personally don't like the concept of default implementation because it spoils the beauty of interface design and a bit on exact polymorphism as well. If somebody is not aware of the concept of ISP then they will start design fat interfaces and will end up like everything packed in one interface. During code design, people will not think logically as well.
This will end up with code smells and I am sure those who don't know the concepts will start writing bad code. I believe default implementation is an unwanted feature as it will tend people to write smelly code.
The ISP will be violated if you intend to do so. You can segregate the interfaces to fulfill only single responsibility. The group of methods for a particular responsibility most probably will follow 80-20 rule. You can provide the default implementations for 40-50% of the methods out of 80% part. This 40-50% part will be the one which will be rarely used and hence defaults are ok. If interface fulfills single responsibility, they will rarely be too big, and most often will be in ISP.
No.
In fact, default methods can be a good way of providing additional useful functionality while avoiding violating ISP.
An excerpt from my longer answer here:
There are examples in the standard library of good uses default methods. One would be java.util.function.Function with its andThen(...) and compose(...) methods. ...
These default methods do not violate ISP, as classes that implement Function have no need to call or override them. There may be many use-cases where concrete instances of Function never have their andThen(...) method called, but that's fine – you don't break ISP by providing useful but non-essential functionality, as long as you don't encumber all those use-cases by forcing them to do something with it. In the case of Function, providing these methods as abstract rather than default would violate ISP, as all implementing classes would have to add their own implementations, even when they know it's unlikely to ever be called.
The quote in the OP is not quite accurate. The actual statement of the ISP is,
Clients should not be forced to depend upon interfaces that they do not use.
The client is the consumer of the interface, i.e. the caller of its abstract methods. The client is not the implementer of the interface. If we are following the dependency inversion principle, the client should not even know the concrete implementation of the interface.
The reasoning behind the ISP is not to save developers from implementing additional abstract methods. It is to save the caller of those methods from unnecessary transitive dependencies. Additional interface methods risk pulling in additional dependencies (via declaration or implementation). A client who doesn't use those methods still acquires those dependencies and becomes coupled to clients who do use those methods through the changes those clients force upon the interface and its shared implementation.
Applying this principle to default methods in Java 8, it is certainly possible for such a method to violate the ISP by adding dependencies that not all clients require. On the other hand, it is also possible (and preferable) for a default method to not add any dependency and to never change in any way that breaks clients.
In summary, default methods are just another tool. They may be used to help your code or to hurt it.
© 2022 - 2024 — McMap. All rights reserved.
