How do I avoid breaking the Liskov substitution principle with a class that implements multiple interfaces?
Given the following class:
class Example implements Interface1, Interface2{
...
}
When I instantiate the class using interface1:
Interface1 example = new Example();
Then I can call only the Interface1 methods, and not the Interface2 methods, unless I cast:
((Interface2) example).someInterface2Method();
Of course, to make this runtime safe, I should also wrap this with an instanceof
check:
if (example instanceof Interface2) {
((Interface2) example).someInterface2Method();
}
I'm aware that I could have a wrapper interface that extends both interfaces, but then I could end up with multiple interfaces to cater for all the possible permutations of interfaces that can be implemented by the same class. The Interfaces in question do not naturally extend one another so inheritance also seems wrong.
Does the instanceof / cast approach break LSP as I am interrogating the runtime instance to determine its implementations? Whichever implementation I use seems to have some side-effect either in bad design or usage.
java lsp
add a comment |
Given the following class:
class Example implements Interface1, Interface2{
...
}
When I instantiate the class using interface1:
Interface1 example = new Example();
Then I can call only the Interface1 methods, and not the Interface2 methods, unless I cast:
((Interface2) example).someInterface2Method();
Of course, to make this runtime safe, I should also wrap this with an instanceof
check:
if (example instanceof Interface2) {
((Interface2) example).someInterface2Method();
}
I'm aware that I could have a wrapper interface that extends both interfaces, but then I could end up with multiple interfaces to cater for all the possible permutations of interfaces that can be implemented by the same class. The Interfaces in question do not naturally extend one another so inheritance also seems wrong.
Does the instanceof / cast approach break LSP as I am interrogating the runtime instance to determine its implementations? Whichever implementation I use seems to have some side-effect either in bad design or usage.
java lsp
15
I wouldn't add the check. If I had to have both interfaces in play in a single scope I'd make the compile time type Example, not Interface1.
– duffymo
15 hours ago
1
You definitely don't need to cast in this situation. It should always be a last resort. Probably more than 90% of casts are simply a result of bad design.
– Michael
15 hours ago
6
create a third interface which extends those 2 you've mentioned and use the former throughout your code. or use generics to be more forgiving:public <T extends Interfac1 & Interface2> void doSomething(T t)
– Lino
15 hours ago
5
Can't you useExample example = new Example();
?
– Andy Turner
15 hours ago
Given that casts are a reasonable feature of the Java language, we can't answer these questions without knowing the purpose of the class and interfaces and why you want to cast.
– Matt Timmermans
15 hours ago
add a comment |
Given the following class:
class Example implements Interface1, Interface2{
...
}
When I instantiate the class using interface1:
Interface1 example = new Example();
Then I can call only the Interface1 methods, and not the Interface2 methods, unless I cast:
((Interface2) example).someInterface2Method();
Of course, to make this runtime safe, I should also wrap this with an instanceof
check:
if (example instanceof Interface2) {
((Interface2) example).someInterface2Method();
}
I'm aware that I could have a wrapper interface that extends both interfaces, but then I could end up with multiple interfaces to cater for all the possible permutations of interfaces that can be implemented by the same class. The Interfaces in question do not naturally extend one another so inheritance also seems wrong.
Does the instanceof / cast approach break LSP as I am interrogating the runtime instance to determine its implementations? Whichever implementation I use seems to have some side-effect either in bad design or usage.
java lsp
Given the following class:
class Example implements Interface1, Interface2{
...
}
When I instantiate the class using interface1:
Interface1 example = new Example();
Then I can call only the Interface1 methods, and not the Interface2 methods, unless I cast:
((Interface2) example).someInterface2Method();
Of course, to make this runtime safe, I should also wrap this with an instanceof
check:
if (example instanceof Interface2) {
((Interface2) example).someInterface2Method();
}
I'm aware that I could have a wrapper interface that extends both interfaces, but then I could end up with multiple interfaces to cater for all the possible permutations of interfaces that can be implemented by the same class. The Interfaces in question do not naturally extend one another so inheritance also seems wrong.
Does the instanceof / cast approach break LSP as I am interrogating the runtime instance to determine its implementations? Whichever implementation I use seems to have some side-effect either in bad design or usage.
java lsp
java lsp
edited 43 mins ago
Peter Mortensen
13.5k1984111
13.5k1984111
asked 15 hours ago
jmljml
713
713
15
I wouldn't add the check. If I had to have both interfaces in play in a single scope I'd make the compile time type Example, not Interface1.
– duffymo
15 hours ago
1
You definitely don't need to cast in this situation. It should always be a last resort. Probably more than 90% of casts are simply a result of bad design.
– Michael
15 hours ago
6
create a third interface which extends those 2 you've mentioned and use the former throughout your code. or use generics to be more forgiving:public <T extends Interfac1 & Interface2> void doSomething(T t)
– Lino
15 hours ago
5
Can't you useExample example = new Example();
?
– Andy Turner
15 hours ago
Given that casts are a reasonable feature of the Java language, we can't answer these questions without knowing the purpose of the class and interfaces and why you want to cast.
– Matt Timmermans
15 hours ago
add a comment |
15
I wouldn't add the check. If I had to have both interfaces in play in a single scope I'd make the compile time type Example, not Interface1.
– duffymo
15 hours ago
1
You definitely don't need to cast in this situation. It should always be a last resort. Probably more than 90% of casts are simply a result of bad design.
– Michael
15 hours ago
6
create a third interface which extends those 2 you've mentioned and use the former throughout your code. or use generics to be more forgiving:public <T extends Interfac1 & Interface2> void doSomething(T t)
– Lino
15 hours ago
5
Can't you useExample example = new Example();
?
– Andy Turner
15 hours ago
Given that casts are a reasonable feature of the Java language, we can't answer these questions without knowing the purpose of the class and interfaces and why you want to cast.
– Matt Timmermans
15 hours ago
15
15
I wouldn't add the check. If I had to have both interfaces in play in a single scope I'd make the compile time type Example, not Interface1.
– duffymo
15 hours ago
I wouldn't add the check. If I had to have both interfaces in play in a single scope I'd make the compile time type Example, not Interface1.
– duffymo
15 hours ago
1
1
You definitely don't need to cast in this situation. It should always be a last resort. Probably more than 90% of casts are simply a result of bad design.
– Michael
15 hours ago
You definitely don't need to cast in this situation. It should always be a last resort. Probably more than 90% of casts are simply a result of bad design.
– Michael
15 hours ago
6
6
create a third interface which extends those 2 you've mentioned and use the former throughout your code. or use generics to be more forgiving:
public <T extends Interfac1 & Interface2> void doSomething(T t)
– Lino
15 hours ago
create a third interface which extends those 2 you've mentioned and use the former throughout your code. or use generics to be more forgiving:
public <T extends Interfac1 & Interface2> void doSomething(T t)
– Lino
15 hours ago
5
5
Can't you use
Example example = new Example();
?– Andy Turner
15 hours ago
Can't you use
Example example = new Example();
?– Andy Turner
15 hours ago
Given that casts are a reasonable feature of the Java language, we can't answer these questions without knowing the purpose of the class and interfaces and why you want to cast.
– Matt Timmermans
15 hours ago
Given that casts are a reasonable feature of the Java language, we can't answer these questions without knowing the purpose of the class and interfaces and why you want to cast.
– Matt Timmermans
15 hours ago
add a comment |
6 Answers
6
active
oldest
votes
I'm aware that I could have a wrapper interface that extends both
interfaces, but then I could end up with multiple interfaces to cater
for all the possible permutations of interfaces that can be
implemented by the same class
I suspect that if you're finding that lots of your classes implement different combinations of interfaces then either: your concrete classes are doing too much; or (less likely) your interfaces are too small and too specialised, to the point of being useless individually.
If you have good reason for some code to require something that is both a Interface1
and a Interface2
then absolutely go ahead and make a combined version that extends both. If you struggle to think of an appropriate name for this (no, not FooAndBar
) then that's an indicator that your design is wrong.
Absolutely do not rely on casting anything. It should only be used as a last resort and usually only for very specific problems (e.g. serialization).
My favourite and most-used design pattern is the decorator pattern as such most of my classes will only ever implement one interface (except for more generic interfaces such as Comparable
). I would say that if your classes are frequently/always implementing more than one interface then that's a code smell.
If you're instantiating the object and using it within the same scope then you should just be writing
Example example = new Example();
Just so it's clear (I'm not sure if this is what you were suggesting), under no circumstances should you ever be writing anything like this:
Interface1 example = new Example();
if (example instanceof Interface2) {
((Interface2) example).someInterface2Method();
}
It is an interesting point you make when you say "to the point of being useless individually" - Interface2 in this example actually refers to an interface I have called HasParameters, which has methods getParams() and setParams() as not all implementations of Interface1 actually need to work with params. I was attempting to not break the Interface Segregation Principle, by having lots of implementations with empty getParams() and setParams() methods but like you say, Interface2 is pretty useless on its own...
– jml
15 hours ago
2
@jml then maybe a specification of Interface1 with your said methods would be better (interface Interface2 extends Interface1 { /* get and set params */ }
– Lino
15 hours ago
1
@jml Then what Lino suggests is probably what you want.Request
andParametizedRequest
are better thanRequest
andHasParameters
.
– Michael
14 hours ago
2
@jmlHasParameters
doesn't feel like an interface, but an attribute. Maybe in reality what you need to do is add the methods toRequest
, likehasParameters()
,getParameters()
andsetParameters()
. With Java 8 you can even have thosedefault
tofalse
,emptyList()
andthrow OperationNotSupportedException
respectively if you don't want to have to implement them all the time. Java's Collection classes do this all the time.
– jbx
12 hours ago
1
With Java 8 you could include yourgetParams()
andsetParams()
inInterface1
with default do-nothing implementations, likepublic default void setParams(Params p) {}
andpublic default Params getParams() { return null; }
– Stephen P
11 hours ago
|
show 4 more comments
Your class can implement multiple interfaces fine, and it is not breaking any OOP principles. On the contrary, it is following the interface segregation principle.
It is confusing why would you have a situation where something of type Interface1
is expected to provide someInterface2Method()
. That is where your design is wrong.
Think about it in a slightly different way: Where you have void method1(Interface1 interface1)
, you wouldn't expect this to expect interface1
to also be an instance of Interface2
. If it was the case, the type of the argument should have been different.
If you want to be able to call both methods, you should have the type of your variable example
set to Example
. That way you avoid the instanceof
and type casting altogether.
If your two interfaces Interface1
and Interface2
are not that loosely coupled, and you will often need to call methods from both, maybe separating the interfaces wasn't such a good idea, or maybe you want to have another interface which extends both.
In general (although not always), instanceof
checks and type casts often indicate some OO design flaw. Sometimes the design would fit for the rest of the program, but you would have a small case where it is simpler to type cast rather than refactor everything. But if possible you should always strive to avoid it at first, as part of your design.
add a comment |
You have two different options (I bet there are a lot more).
The first is to create your own interface
which extends the other two:
interface Interface3 extends Interface1, Interface2 {}
And then use that throughout your code:
public void doSomething(Interface3 interface3){
...
}
The other way (and in my opinion the better one) is to use generics per method:
public <T extends Interface1 & Interface2> void doSomething(T t){
...
}
The latter option is in fact less restricted than the former, because the generic type T
gets dynamically inferred and thus leads to less coupling (a class doesn't have to implement a specific grouping interface, like the first example).
1
"And then use that throughout your code" The significant downside to this is that you have to makeExample
(and any other classes) implement this class.
– Andy Turner
15 hours ago
@Andy I agree and that's why the second approach is more flexible and may probably be preferred
– Lino
15 hours ago
5
It's worth stating your preferred option first; or, at the very least, stating "My preferred way" or similar, which is a much stronger endorsement than "the other way".
– Andy Turner
15 hours ago
3
While you are providing correct technical solutions to the issue, be wary of implementing workarounds when the underlying issue is an architecture one. You may find yourself with even more issues in the end stemming from an incorrect design.
– Vincent Savard
11 hours ago
add a comment |
Your example does not break LSV, but it seems to break SRP. If you encounter such case where you need to cast an object to its 2nd interface, the method that contains such code can be considered busy.
Implementing 2 (or more) interfaces in a class is fine. In deciding which interface to use as its data type depends entirely on the context of the code that will use it.
Casting is fine, especially when changing context.
class Payment implements Expirable, Limited {
/* ... */
}
class PaymentProcessor {
// Using payment here because i'm working with payments.
public void process(Payment payment) {
boolean expired = expirationChecker.check(payment);
boolean pastLimit = limitChecker.check(payment);
if (!expired && !pastLimit) {
acceptPayment(payment);
}
}
}
class ExpirationChecker {
// This the `Expirable` world, so i'm using Expirable here
public boolean check(Expirable expirable) {
// code
}
}
class LimitChecker {
// This class is about checking limits, thats why im using `Limited` here
public boolean check(Limited limited) {
// code
}
}
LSV? Don't you mean LSP?
– Peter Mortensen
41 mins ago
add a comment |
Usually, many, client-specific interfaces are fine, and somewhat part of the Interface segregation principle (the "I" in SOLID). Some more specific points, on a technical level, have already been mentioned in other answers.
Particularly that you can go too far with this segregation, by having a class like
class Person implements FirstNameProvider, LastNameProvider, AgeProvider ... {
@Override String getFirstName() {...}
@Override String getLastName() {...}
@Override int getAge() {...}
...
}
Or, conversely, that you have an implementing class that is too powerful, as in
class Application implements DatabaseReader, DataProcessor, UserInteraction, Visualizer {
...
}
I think that the main point in the Interface Segregation Principle is that the interfaces should be client-specific. They should basically "summarize" the functions that are required by a certain client, for a certain task.
To put it that way: The issue is to strike the right balance between the extremes that I sketched above. When I'm trying to figure out interfaces and their relationships (mutually, and in terms of the classes that implement them), I always try to take a step back and ask myself, in an intentionally naïve way: Who is going to receive what, and what is he going to do with it?
Regarding your example: When all your clients always need the functionality of Interface1
and Interface2
at the same time, then you should consider either defining an
interface Combined extends Interface1, Interface2 { }
or not have different interfaces in the first place. On the other hand, when the functionalities are completely distinct and unrelated and never used together, then you should wonder why the single class is implementing them at the same time.
At this point, one could refer to another principle, namely Composition over inheritance. Although it is not classically related to implementing multiple interfaces, composition can also be favorable in this case. For example, you could change your class to not implement the interfaces directly, but only provide instances that implement them:
class Example {
Interface1 getInterface1() { ... }
Interface2 getInterface2() { ... }
}
(Note: It looks a bit odd in this Example
(sic!), but depending on the complexity of the implementation of Interface1
and Interface2
, it can really make sense to keep them separated)
This is the correct answer. The interface is built for the contract that the client code needs fulfilled. If the client code reasonably expects to be able to call someInterface1Method AND someInterface2Method, then that is a new contract. From wikipedia on ISP: "no client should be forced to depend on methods it does not use." and "clients will only have to know about the methods that are of interest to them."
– Xtros
7 hours ago
add a comment |
The problem you describe often comes about through over-zealous application of the Interface Segregation Principle, encouraged by languages' inability to specify that members of one interface should, by default, be chained to static methods which could implement sensible behaviors.
Consider, for example, a basic sequence/enumeration interface and the following behaviors:
Produce an enumerator which can read out the objects if no other iterator has yet been created.
Produce an enumerator which can read out the objects even if another iterator has already been created and used.
Report how many items are in the sequence
Report the value of the Nth item in the sequence
Copy a range of items from the object into an array of that type.
Yield a reference to an immutable object that can accommodate the above operations efficiently with contents that are guaranteed never to change.
I would suggest that such abilities should be part of the basic sequence/enumeration interface, along with a method/property to indicate which of the above operations are meaningfully supported. Some kinds of single-shot on-demand enumerators (e.g. an infinite truly-random sequence generator) might not be able to support any of those functions, but segregating such functions into separate interfaces will make it much harder to produce efficient wrappers for many kinds of operations.
One could produce a wrapper class that would accommodate all of the above operations, though not necessarily efficiently, on any finite sequence which supports the first ability. If, however, the class is being used to wrap an object that already supports some of those abilities (e.g. access the Nth item), having the wrapper use the underlying behaviors could be much more efficient than having it do everything via the second function above (e.g. creating a new enumerator, and using that to iteratively read and ignore items from the sequence until the desired one is reached).
Having all objects that produce any kind of sequence support an interface that includes all of the above, along with an indication of what abilities are supported, would be cleaner than trying to have different interfaces for different subsets of abilities, and requiring that wrapper classes make explicit provision for any combinations they want to expose to their clients.
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54184354%2fhow-do-i-avoid-breaking-the-liskov-substitution-principle-with-a-class-that-impl%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
6 Answers
6
active
oldest
votes
6 Answers
6
active
oldest
votes
active
oldest
votes
active
oldest
votes
I'm aware that I could have a wrapper interface that extends both
interfaces, but then I could end up with multiple interfaces to cater
for all the possible permutations of interfaces that can be
implemented by the same class
I suspect that if you're finding that lots of your classes implement different combinations of interfaces then either: your concrete classes are doing too much; or (less likely) your interfaces are too small and too specialised, to the point of being useless individually.
If you have good reason for some code to require something that is both a Interface1
and a Interface2
then absolutely go ahead and make a combined version that extends both. If you struggle to think of an appropriate name for this (no, not FooAndBar
) then that's an indicator that your design is wrong.
Absolutely do not rely on casting anything. It should only be used as a last resort and usually only for very specific problems (e.g. serialization).
My favourite and most-used design pattern is the decorator pattern as such most of my classes will only ever implement one interface (except for more generic interfaces such as Comparable
). I would say that if your classes are frequently/always implementing more than one interface then that's a code smell.
If you're instantiating the object and using it within the same scope then you should just be writing
Example example = new Example();
Just so it's clear (I'm not sure if this is what you were suggesting), under no circumstances should you ever be writing anything like this:
Interface1 example = new Example();
if (example instanceof Interface2) {
((Interface2) example).someInterface2Method();
}
It is an interesting point you make when you say "to the point of being useless individually" - Interface2 in this example actually refers to an interface I have called HasParameters, which has methods getParams() and setParams() as not all implementations of Interface1 actually need to work with params. I was attempting to not break the Interface Segregation Principle, by having lots of implementations with empty getParams() and setParams() methods but like you say, Interface2 is pretty useless on its own...
– jml
15 hours ago
2
@jml then maybe a specification of Interface1 with your said methods would be better (interface Interface2 extends Interface1 { /* get and set params */ }
– Lino
15 hours ago
1
@jml Then what Lino suggests is probably what you want.Request
andParametizedRequest
are better thanRequest
andHasParameters
.
– Michael
14 hours ago
2
@jmlHasParameters
doesn't feel like an interface, but an attribute. Maybe in reality what you need to do is add the methods toRequest
, likehasParameters()
,getParameters()
andsetParameters()
. With Java 8 you can even have thosedefault
tofalse
,emptyList()
andthrow OperationNotSupportedException
respectively if you don't want to have to implement them all the time. Java's Collection classes do this all the time.
– jbx
12 hours ago
1
With Java 8 you could include yourgetParams()
andsetParams()
inInterface1
with default do-nothing implementations, likepublic default void setParams(Params p) {}
andpublic default Params getParams() { return null; }
– Stephen P
11 hours ago
|
show 4 more comments
I'm aware that I could have a wrapper interface that extends both
interfaces, but then I could end up with multiple interfaces to cater
for all the possible permutations of interfaces that can be
implemented by the same class
I suspect that if you're finding that lots of your classes implement different combinations of interfaces then either: your concrete classes are doing too much; or (less likely) your interfaces are too small and too specialised, to the point of being useless individually.
If you have good reason for some code to require something that is both a Interface1
and a Interface2
then absolutely go ahead and make a combined version that extends both. If you struggle to think of an appropriate name for this (no, not FooAndBar
) then that's an indicator that your design is wrong.
Absolutely do not rely on casting anything. It should only be used as a last resort and usually only for very specific problems (e.g. serialization).
My favourite and most-used design pattern is the decorator pattern as such most of my classes will only ever implement one interface (except for more generic interfaces such as Comparable
). I would say that if your classes are frequently/always implementing more than one interface then that's a code smell.
If you're instantiating the object and using it within the same scope then you should just be writing
Example example = new Example();
Just so it's clear (I'm not sure if this is what you were suggesting), under no circumstances should you ever be writing anything like this:
Interface1 example = new Example();
if (example instanceof Interface2) {
((Interface2) example).someInterface2Method();
}
It is an interesting point you make when you say "to the point of being useless individually" - Interface2 in this example actually refers to an interface I have called HasParameters, which has methods getParams() and setParams() as not all implementations of Interface1 actually need to work with params. I was attempting to not break the Interface Segregation Principle, by having lots of implementations with empty getParams() and setParams() methods but like you say, Interface2 is pretty useless on its own...
– jml
15 hours ago
2
@jml then maybe a specification of Interface1 with your said methods would be better (interface Interface2 extends Interface1 { /* get and set params */ }
– Lino
15 hours ago
1
@jml Then what Lino suggests is probably what you want.Request
andParametizedRequest
are better thanRequest
andHasParameters
.
– Michael
14 hours ago
2
@jmlHasParameters
doesn't feel like an interface, but an attribute. Maybe in reality what you need to do is add the methods toRequest
, likehasParameters()
,getParameters()
andsetParameters()
. With Java 8 you can even have thosedefault
tofalse
,emptyList()
andthrow OperationNotSupportedException
respectively if you don't want to have to implement them all the time. Java's Collection classes do this all the time.
– jbx
12 hours ago
1
With Java 8 you could include yourgetParams()
andsetParams()
inInterface1
with default do-nothing implementations, likepublic default void setParams(Params p) {}
andpublic default Params getParams() { return null; }
– Stephen P
11 hours ago
|
show 4 more comments
I'm aware that I could have a wrapper interface that extends both
interfaces, but then I could end up with multiple interfaces to cater
for all the possible permutations of interfaces that can be
implemented by the same class
I suspect that if you're finding that lots of your classes implement different combinations of interfaces then either: your concrete classes are doing too much; or (less likely) your interfaces are too small and too specialised, to the point of being useless individually.
If you have good reason for some code to require something that is both a Interface1
and a Interface2
then absolutely go ahead and make a combined version that extends both. If you struggle to think of an appropriate name for this (no, not FooAndBar
) then that's an indicator that your design is wrong.
Absolutely do not rely on casting anything. It should only be used as a last resort and usually only for very specific problems (e.g. serialization).
My favourite and most-used design pattern is the decorator pattern as such most of my classes will only ever implement one interface (except for more generic interfaces such as Comparable
). I would say that if your classes are frequently/always implementing more than one interface then that's a code smell.
If you're instantiating the object and using it within the same scope then you should just be writing
Example example = new Example();
Just so it's clear (I'm not sure if this is what you were suggesting), under no circumstances should you ever be writing anything like this:
Interface1 example = new Example();
if (example instanceof Interface2) {
((Interface2) example).someInterface2Method();
}
I'm aware that I could have a wrapper interface that extends both
interfaces, but then I could end up with multiple interfaces to cater
for all the possible permutations of interfaces that can be
implemented by the same class
I suspect that if you're finding that lots of your classes implement different combinations of interfaces then either: your concrete classes are doing too much; or (less likely) your interfaces are too small and too specialised, to the point of being useless individually.
If you have good reason for some code to require something that is both a Interface1
and a Interface2
then absolutely go ahead and make a combined version that extends both. If you struggle to think of an appropriate name for this (no, not FooAndBar
) then that's an indicator that your design is wrong.
Absolutely do not rely on casting anything. It should only be used as a last resort and usually only for very specific problems (e.g. serialization).
My favourite and most-used design pattern is the decorator pattern as such most of my classes will only ever implement one interface (except for more generic interfaces such as Comparable
). I would say that if your classes are frequently/always implementing more than one interface then that's a code smell.
If you're instantiating the object and using it within the same scope then you should just be writing
Example example = new Example();
Just so it's clear (I'm not sure if this is what you were suggesting), under no circumstances should you ever be writing anything like this:
Interface1 example = new Example();
if (example instanceof Interface2) {
((Interface2) example).someInterface2Method();
}
edited 15 hours ago
answered 15 hours ago
MichaelMichael
18.9k73369
18.9k73369
It is an interesting point you make when you say "to the point of being useless individually" - Interface2 in this example actually refers to an interface I have called HasParameters, which has methods getParams() and setParams() as not all implementations of Interface1 actually need to work with params. I was attempting to not break the Interface Segregation Principle, by having lots of implementations with empty getParams() and setParams() methods but like you say, Interface2 is pretty useless on its own...
– jml
15 hours ago
2
@jml then maybe a specification of Interface1 with your said methods would be better (interface Interface2 extends Interface1 { /* get and set params */ }
– Lino
15 hours ago
1
@jml Then what Lino suggests is probably what you want.Request
andParametizedRequest
are better thanRequest
andHasParameters
.
– Michael
14 hours ago
2
@jmlHasParameters
doesn't feel like an interface, but an attribute. Maybe in reality what you need to do is add the methods toRequest
, likehasParameters()
,getParameters()
andsetParameters()
. With Java 8 you can even have thosedefault
tofalse
,emptyList()
andthrow OperationNotSupportedException
respectively if you don't want to have to implement them all the time. Java's Collection classes do this all the time.
– jbx
12 hours ago
1
With Java 8 you could include yourgetParams()
andsetParams()
inInterface1
with default do-nothing implementations, likepublic default void setParams(Params p) {}
andpublic default Params getParams() { return null; }
– Stephen P
11 hours ago
|
show 4 more comments
It is an interesting point you make when you say "to the point of being useless individually" - Interface2 in this example actually refers to an interface I have called HasParameters, which has methods getParams() and setParams() as not all implementations of Interface1 actually need to work with params. I was attempting to not break the Interface Segregation Principle, by having lots of implementations with empty getParams() and setParams() methods but like you say, Interface2 is pretty useless on its own...
– jml
15 hours ago
2
@jml then maybe a specification of Interface1 with your said methods would be better (interface Interface2 extends Interface1 { /* get and set params */ }
– Lino
15 hours ago
1
@jml Then what Lino suggests is probably what you want.Request
andParametizedRequest
are better thanRequest
andHasParameters
.
– Michael
14 hours ago
2
@jmlHasParameters
doesn't feel like an interface, but an attribute. Maybe in reality what you need to do is add the methods toRequest
, likehasParameters()
,getParameters()
andsetParameters()
. With Java 8 you can even have thosedefault
tofalse
,emptyList()
andthrow OperationNotSupportedException
respectively if you don't want to have to implement them all the time. Java's Collection classes do this all the time.
– jbx
12 hours ago
1
With Java 8 you could include yourgetParams()
andsetParams()
inInterface1
with default do-nothing implementations, likepublic default void setParams(Params p) {}
andpublic default Params getParams() { return null; }
– Stephen P
11 hours ago
It is an interesting point you make when you say "to the point of being useless individually" - Interface2 in this example actually refers to an interface I have called HasParameters, which has methods getParams() and setParams() as not all implementations of Interface1 actually need to work with params. I was attempting to not break the Interface Segregation Principle, by having lots of implementations with empty getParams() and setParams() methods but like you say, Interface2 is pretty useless on its own...
– jml
15 hours ago
It is an interesting point you make when you say "to the point of being useless individually" - Interface2 in this example actually refers to an interface I have called HasParameters, which has methods getParams() and setParams() as not all implementations of Interface1 actually need to work with params. I was attempting to not break the Interface Segregation Principle, by having lots of implementations with empty getParams() and setParams() methods but like you say, Interface2 is pretty useless on its own...
– jml
15 hours ago
2
2
@jml then maybe a specification of Interface1 with your said methods would be better (
interface Interface2 extends Interface1 { /* get and set params */ }
– Lino
15 hours ago
@jml then maybe a specification of Interface1 with your said methods would be better (
interface Interface2 extends Interface1 { /* get and set params */ }
– Lino
15 hours ago
1
1
@jml Then what Lino suggests is probably what you want.
Request
and ParametizedRequest
are better than Request
and HasParameters
.– Michael
14 hours ago
@jml Then what Lino suggests is probably what you want.
Request
and ParametizedRequest
are better than Request
and HasParameters
.– Michael
14 hours ago
2
2
@jml
HasParameters
doesn't feel like an interface, but an attribute. Maybe in reality what you need to do is add the methods to Request
, like hasParameters()
, getParameters()
and setParameters()
. With Java 8 you can even have those default
to false
, emptyList()
and throw OperationNotSupportedException
respectively if you don't want to have to implement them all the time. Java's Collection classes do this all the time.– jbx
12 hours ago
@jml
HasParameters
doesn't feel like an interface, but an attribute. Maybe in reality what you need to do is add the methods to Request
, like hasParameters()
, getParameters()
and setParameters()
. With Java 8 you can even have those default
to false
, emptyList()
and throw OperationNotSupportedException
respectively if you don't want to have to implement them all the time. Java's Collection classes do this all the time.– jbx
12 hours ago
1
1
With Java 8 you could include your
getParams()
and setParams()
in Interface1
with default do-nothing implementations, like public default void setParams(Params p) {}
and public default Params getParams() { return null; }
– Stephen P
11 hours ago
With Java 8 you could include your
getParams()
and setParams()
in Interface1
with default do-nothing implementations, like public default void setParams(Params p) {}
and public default Params getParams() { return null; }
– Stephen P
11 hours ago
|
show 4 more comments
Your class can implement multiple interfaces fine, and it is not breaking any OOP principles. On the contrary, it is following the interface segregation principle.
It is confusing why would you have a situation where something of type Interface1
is expected to provide someInterface2Method()
. That is where your design is wrong.
Think about it in a slightly different way: Where you have void method1(Interface1 interface1)
, you wouldn't expect this to expect interface1
to also be an instance of Interface2
. If it was the case, the type of the argument should have been different.
If you want to be able to call both methods, you should have the type of your variable example
set to Example
. That way you avoid the instanceof
and type casting altogether.
If your two interfaces Interface1
and Interface2
are not that loosely coupled, and you will often need to call methods from both, maybe separating the interfaces wasn't such a good idea, or maybe you want to have another interface which extends both.
In general (although not always), instanceof
checks and type casts often indicate some OO design flaw. Sometimes the design would fit for the rest of the program, but you would have a small case where it is simpler to type cast rather than refactor everything. But if possible you should always strive to avoid it at first, as part of your design.
add a comment |
Your class can implement multiple interfaces fine, and it is not breaking any OOP principles. On the contrary, it is following the interface segregation principle.
It is confusing why would you have a situation where something of type Interface1
is expected to provide someInterface2Method()
. That is where your design is wrong.
Think about it in a slightly different way: Where you have void method1(Interface1 interface1)
, you wouldn't expect this to expect interface1
to also be an instance of Interface2
. If it was the case, the type of the argument should have been different.
If you want to be able to call both methods, you should have the type of your variable example
set to Example
. That way you avoid the instanceof
and type casting altogether.
If your two interfaces Interface1
and Interface2
are not that loosely coupled, and you will often need to call methods from both, maybe separating the interfaces wasn't such a good idea, or maybe you want to have another interface which extends both.
In general (although not always), instanceof
checks and type casts often indicate some OO design flaw. Sometimes the design would fit for the rest of the program, but you would have a small case where it is simpler to type cast rather than refactor everything. But if possible you should always strive to avoid it at first, as part of your design.
add a comment |
Your class can implement multiple interfaces fine, and it is not breaking any OOP principles. On the contrary, it is following the interface segregation principle.
It is confusing why would you have a situation where something of type Interface1
is expected to provide someInterface2Method()
. That is where your design is wrong.
Think about it in a slightly different way: Where you have void method1(Interface1 interface1)
, you wouldn't expect this to expect interface1
to also be an instance of Interface2
. If it was the case, the type of the argument should have been different.
If you want to be able to call both methods, you should have the type of your variable example
set to Example
. That way you avoid the instanceof
and type casting altogether.
If your two interfaces Interface1
and Interface2
are not that loosely coupled, and you will often need to call methods from both, maybe separating the interfaces wasn't such a good idea, or maybe you want to have another interface which extends both.
In general (although not always), instanceof
checks and type casts often indicate some OO design flaw. Sometimes the design would fit for the rest of the program, but you would have a small case where it is simpler to type cast rather than refactor everything. But if possible you should always strive to avoid it at first, as part of your design.
Your class can implement multiple interfaces fine, and it is not breaking any OOP principles. On the contrary, it is following the interface segregation principle.
It is confusing why would you have a situation where something of type Interface1
is expected to provide someInterface2Method()
. That is where your design is wrong.
Think about it in a slightly different way: Where you have void method1(Interface1 interface1)
, you wouldn't expect this to expect interface1
to also be an instance of Interface2
. If it was the case, the type of the argument should have been different.
If you want to be able to call both methods, you should have the type of your variable example
set to Example
. That way you avoid the instanceof
and type casting altogether.
If your two interfaces Interface1
and Interface2
are not that loosely coupled, and you will often need to call methods from both, maybe separating the interfaces wasn't such a good idea, or maybe you want to have another interface which extends both.
In general (although not always), instanceof
checks and type casts often indicate some OO design flaw. Sometimes the design would fit for the rest of the program, but you would have a small case where it is simpler to type cast rather than refactor everything. But if possible you should always strive to avoid it at first, as part of your design.
edited 35 mins ago
Peter Mortensen
13.5k1984111
13.5k1984111
answered 15 hours ago
jbxjbx
10.8k1057111
10.8k1057111
add a comment |
add a comment |
You have two different options (I bet there are a lot more).
The first is to create your own interface
which extends the other two:
interface Interface3 extends Interface1, Interface2 {}
And then use that throughout your code:
public void doSomething(Interface3 interface3){
...
}
The other way (and in my opinion the better one) is to use generics per method:
public <T extends Interface1 & Interface2> void doSomething(T t){
...
}
The latter option is in fact less restricted than the former, because the generic type T
gets dynamically inferred and thus leads to less coupling (a class doesn't have to implement a specific grouping interface, like the first example).
1
"And then use that throughout your code" The significant downside to this is that you have to makeExample
(and any other classes) implement this class.
– Andy Turner
15 hours ago
@Andy I agree and that's why the second approach is more flexible and may probably be preferred
– Lino
15 hours ago
5
It's worth stating your preferred option first; or, at the very least, stating "My preferred way" or similar, which is a much stronger endorsement than "the other way".
– Andy Turner
15 hours ago
3
While you are providing correct technical solutions to the issue, be wary of implementing workarounds when the underlying issue is an architecture one. You may find yourself with even more issues in the end stemming from an incorrect design.
– Vincent Savard
11 hours ago
add a comment |
You have two different options (I bet there are a lot more).
The first is to create your own interface
which extends the other two:
interface Interface3 extends Interface1, Interface2 {}
And then use that throughout your code:
public void doSomething(Interface3 interface3){
...
}
The other way (and in my opinion the better one) is to use generics per method:
public <T extends Interface1 & Interface2> void doSomething(T t){
...
}
The latter option is in fact less restricted than the former, because the generic type T
gets dynamically inferred and thus leads to less coupling (a class doesn't have to implement a specific grouping interface, like the first example).
1
"And then use that throughout your code" The significant downside to this is that you have to makeExample
(and any other classes) implement this class.
– Andy Turner
15 hours ago
@Andy I agree and that's why the second approach is more flexible and may probably be preferred
– Lino
15 hours ago
5
It's worth stating your preferred option first; or, at the very least, stating "My preferred way" or similar, which is a much stronger endorsement than "the other way".
– Andy Turner
15 hours ago
3
While you are providing correct technical solutions to the issue, be wary of implementing workarounds when the underlying issue is an architecture one. You may find yourself with even more issues in the end stemming from an incorrect design.
– Vincent Savard
11 hours ago
add a comment |
You have two different options (I bet there are a lot more).
The first is to create your own interface
which extends the other two:
interface Interface3 extends Interface1, Interface2 {}
And then use that throughout your code:
public void doSomething(Interface3 interface3){
...
}
The other way (and in my opinion the better one) is to use generics per method:
public <T extends Interface1 & Interface2> void doSomething(T t){
...
}
The latter option is in fact less restricted than the former, because the generic type T
gets dynamically inferred and thus leads to less coupling (a class doesn't have to implement a specific grouping interface, like the first example).
You have two different options (I bet there are a lot more).
The first is to create your own interface
which extends the other two:
interface Interface3 extends Interface1, Interface2 {}
And then use that throughout your code:
public void doSomething(Interface3 interface3){
...
}
The other way (and in my opinion the better one) is to use generics per method:
public <T extends Interface1 & Interface2> void doSomething(T t){
...
}
The latter option is in fact less restricted than the former, because the generic type T
gets dynamically inferred and thus leads to less coupling (a class doesn't have to implement a specific grouping interface, like the first example).
edited 42 mins ago
Peter Mortensen
13.5k1984111
13.5k1984111
answered 15 hours ago
LinoLino
7,60621936
7,60621936
1
"And then use that throughout your code" The significant downside to this is that you have to makeExample
(and any other classes) implement this class.
– Andy Turner
15 hours ago
@Andy I agree and that's why the second approach is more flexible and may probably be preferred
– Lino
15 hours ago
5
It's worth stating your preferred option first; or, at the very least, stating "My preferred way" or similar, which is a much stronger endorsement than "the other way".
– Andy Turner
15 hours ago
3
While you are providing correct technical solutions to the issue, be wary of implementing workarounds when the underlying issue is an architecture one. You may find yourself with even more issues in the end stemming from an incorrect design.
– Vincent Savard
11 hours ago
add a comment |
1
"And then use that throughout your code" The significant downside to this is that you have to makeExample
(and any other classes) implement this class.
– Andy Turner
15 hours ago
@Andy I agree and that's why the second approach is more flexible and may probably be preferred
– Lino
15 hours ago
5
It's worth stating your preferred option first; or, at the very least, stating "My preferred way" or similar, which is a much stronger endorsement than "the other way".
– Andy Turner
15 hours ago
3
While you are providing correct technical solutions to the issue, be wary of implementing workarounds when the underlying issue is an architecture one. You may find yourself with even more issues in the end stemming from an incorrect design.
– Vincent Savard
11 hours ago
1
1
"And then use that throughout your code" The significant downside to this is that you have to make
Example
(and any other classes) implement this class.– Andy Turner
15 hours ago
"And then use that throughout your code" The significant downside to this is that you have to make
Example
(and any other classes) implement this class.– Andy Turner
15 hours ago
@Andy I agree and that's why the second approach is more flexible and may probably be preferred
– Lino
15 hours ago
@Andy I agree and that's why the second approach is more flexible and may probably be preferred
– Lino
15 hours ago
5
5
It's worth stating your preferred option first; or, at the very least, stating "My preferred way" or similar, which is a much stronger endorsement than "the other way".
– Andy Turner
15 hours ago
It's worth stating your preferred option first; or, at the very least, stating "My preferred way" or similar, which is a much stronger endorsement than "the other way".
– Andy Turner
15 hours ago
3
3
While you are providing correct technical solutions to the issue, be wary of implementing workarounds when the underlying issue is an architecture one. You may find yourself with even more issues in the end stemming from an incorrect design.
– Vincent Savard
11 hours ago
While you are providing correct technical solutions to the issue, be wary of implementing workarounds when the underlying issue is an architecture one. You may find yourself with even more issues in the end stemming from an incorrect design.
– Vincent Savard
11 hours ago
add a comment |
Your example does not break LSV, but it seems to break SRP. If you encounter such case where you need to cast an object to its 2nd interface, the method that contains such code can be considered busy.
Implementing 2 (or more) interfaces in a class is fine. In deciding which interface to use as its data type depends entirely on the context of the code that will use it.
Casting is fine, especially when changing context.
class Payment implements Expirable, Limited {
/* ... */
}
class PaymentProcessor {
// Using payment here because i'm working with payments.
public void process(Payment payment) {
boolean expired = expirationChecker.check(payment);
boolean pastLimit = limitChecker.check(payment);
if (!expired && !pastLimit) {
acceptPayment(payment);
}
}
}
class ExpirationChecker {
// This the `Expirable` world, so i'm using Expirable here
public boolean check(Expirable expirable) {
// code
}
}
class LimitChecker {
// This class is about checking limits, thats why im using `Limited` here
public boolean check(Limited limited) {
// code
}
}
LSV? Don't you mean LSP?
– Peter Mortensen
41 mins ago
add a comment |
Your example does not break LSV, but it seems to break SRP. If you encounter such case where you need to cast an object to its 2nd interface, the method that contains such code can be considered busy.
Implementing 2 (or more) interfaces in a class is fine. In deciding which interface to use as its data type depends entirely on the context of the code that will use it.
Casting is fine, especially when changing context.
class Payment implements Expirable, Limited {
/* ... */
}
class PaymentProcessor {
// Using payment here because i'm working with payments.
public void process(Payment payment) {
boolean expired = expirationChecker.check(payment);
boolean pastLimit = limitChecker.check(payment);
if (!expired && !pastLimit) {
acceptPayment(payment);
}
}
}
class ExpirationChecker {
// This the `Expirable` world, so i'm using Expirable here
public boolean check(Expirable expirable) {
// code
}
}
class LimitChecker {
// This class is about checking limits, thats why im using `Limited` here
public boolean check(Limited limited) {
// code
}
}
LSV? Don't you mean LSP?
– Peter Mortensen
41 mins ago
add a comment |
Your example does not break LSV, but it seems to break SRP. If you encounter such case where you need to cast an object to its 2nd interface, the method that contains such code can be considered busy.
Implementing 2 (or more) interfaces in a class is fine. In deciding which interface to use as its data type depends entirely on the context of the code that will use it.
Casting is fine, especially when changing context.
class Payment implements Expirable, Limited {
/* ... */
}
class PaymentProcessor {
// Using payment here because i'm working with payments.
public void process(Payment payment) {
boolean expired = expirationChecker.check(payment);
boolean pastLimit = limitChecker.check(payment);
if (!expired && !pastLimit) {
acceptPayment(payment);
}
}
}
class ExpirationChecker {
// This the `Expirable` world, so i'm using Expirable here
public boolean check(Expirable expirable) {
// code
}
}
class LimitChecker {
// This class is about checking limits, thats why im using `Limited` here
public boolean check(Limited limited) {
// code
}
}
Your example does not break LSV, but it seems to break SRP. If you encounter such case where you need to cast an object to its 2nd interface, the method that contains such code can be considered busy.
Implementing 2 (or more) interfaces in a class is fine. In deciding which interface to use as its data type depends entirely on the context of the code that will use it.
Casting is fine, especially when changing context.
class Payment implements Expirable, Limited {
/* ... */
}
class PaymentProcessor {
// Using payment here because i'm working with payments.
public void process(Payment payment) {
boolean expired = expirationChecker.check(payment);
boolean pastLimit = limitChecker.check(payment);
if (!expired && !pastLimit) {
acceptPayment(payment);
}
}
}
class ExpirationChecker {
// This the `Expirable` world, so i'm using Expirable here
public boolean check(Expirable expirable) {
// code
}
}
class LimitChecker {
// This class is about checking limits, thats why im using `Limited` here
public boolean check(Limited limited) {
// code
}
}
answered 15 hours ago
KaNa0011KaNa0011
469311
469311
LSV? Don't you mean LSP?
– Peter Mortensen
41 mins ago
add a comment |
LSV? Don't you mean LSP?
– Peter Mortensen
41 mins ago
LSV? Don't you mean LSP?
– Peter Mortensen
41 mins ago
LSV? Don't you mean LSP?
– Peter Mortensen
41 mins ago
add a comment |
Usually, many, client-specific interfaces are fine, and somewhat part of the Interface segregation principle (the "I" in SOLID). Some more specific points, on a technical level, have already been mentioned in other answers.
Particularly that you can go too far with this segregation, by having a class like
class Person implements FirstNameProvider, LastNameProvider, AgeProvider ... {
@Override String getFirstName() {...}
@Override String getLastName() {...}
@Override int getAge() {...}
...
}
Or, conversely, that you have an implementing class that is too powerful, as in
class Application implements DatabaseReader, DataProcessor, UserInteraction, Visualizer {
...
}
I think that the main point in the Interface Segregation Principle is that the interfaces should be client-specific. They should basically "summarize" the functions that are required by a certain client, for a certain task.
To put it that way: The issue is to strike the right balance between the extremes that I sketched above. When I'm trying to figure out interfaces and their relationships (mutually, and in terms of the classes that implement them), I always try to take a step back and ask myself, in an intentionally naïve way: Who is going to receive what, and what is he going to do with it?
Regarding your example: When all your clients always need the functionality of Interface1
and Interface2
at the same time, then you should consider either defining an
interface Combined extends Interface1, Interface2 { }
or not have different interfaces in the first place. On the other hand, when the functionalities are completely distinct and unrelated and never used together, then you should wonder why the single class is implementing them at the same time.
At this point, one could refer to another principle, namely Composition over inheritance. Although it is not classically related to implementing multiple interfaces, composition can also be favorable in this case. For example, you could change your class to not implement the interfaces directly, but only provide instances that implement them:
class Example {
Interface1 getInterface1() { ... }
Interface2 getInterface2() { ... }
}
(Note: It looks a bit odd in this Example
(sic!), but depending on the complexity of the implementation of Interface1
and Interface2
, it can really make sense to keep them separated)
This is the correct answer. The interface is built for the contract that the client code needs fulfilled. If the client code reasonably expects to be able to call someInterface1Method AND someInterface2Method, then that is a new contract. From wikipedia on ISP: "no client should be forced to depend on methods it does not use." and "clients will only have to know about the methods that are of interest to them."
– Xtros
7 hours ago
add a comment |
Usually, many, client-specific interfaces are fine, and somewhat part of the Interface segregation principle (the "I" in SOLID). Some more specific points, on a technical level, have already been mentioned in other answers.
Particularly that you can go too far with this segregation, by having a class like
class Person implements FirstNameProvider, LastNameProvider, AgeProvider ... {
@Override String getFirstName() {...}
@Override String getLastName() {...}
@Override int getAge() {...}
...
}
Or, conversely, that you have an implementing class that is too powerful, as in
class Application implements DatabaseReader, DataProcessor, UserInteraction, Visualizer {
...
}
I think that the main point in the Interface Segregation Principle is that the interfaces should be client-specific. They should basically "summarize" the functions that are required by a certain client, for a certain task.
To put it that way: The issue is to strike the right balance between the extremes that I sketched above. When I'm trying to figure out interfaces and their relationships (mutually, and in terms of the classes that implement them), I always try to take a step back and ask myself, in an intentionally naïve way: Who is going to receive what, and what is he going to do with it?
Regarding your example: When all your clients always need the functionality of Interface1
and Interface2
at the same time, then you should consider either defining an
interface Combined extends Interface1, Interface2 { }
or not have different interfaces in the first place. On the other hand, when the functionalities are completely distinct and unrelated and never used together, then you should wonder why the single class is implementing them at the same time.
At this point, one could refer to another principle, namely Composition over inheritance. Although it is not classically related to implementing multiple interfaces, composition can also be favorable in this case. For example, you could change your class to not implement the interfaces directly, but only provide instances that implement them:
class Example {
Interface1 getInterface1() { ... }
Interface2 getInterface2() { ... }
}
(Note: It looks a bit odd in this Example
(sic!), but depending on the complexity of the implementation of Interface1
and Interface2
, it can really make sense to keep them separated)
This is the correct answer. The interface is built for the contract that the client code needs fulfilled. If the client code reasonably expects to be able to call someInterface1Method AND someInterface2Method, then that is a new contract. From wikipedia on ISP: "no client should be forced to depend on methods it does not use." and "clients will only have to know about the methods that are of interest to them."
– Xtros
7 hours ago
add a comment |
Usually, many, client-specific interfaces are fine, and somewhat part of the Interface segregation principle (the "I" in SOLID). Some more specific points, on a technical level, have already been mentioned in other answers.
Particularly that you can go too far with this segregation, by having a class like
class Person implements FirstNameProvider, LastNameProvider, AgeProvider ... {
@Override String getFirstName() {...}
@Override String getLastName() {...}
@Override int getAge() {...}
...
}
Or, conversely, that you have an implementing class that is too powerful, as in
class Application implements DatabaseReader, DataProcessor, UserInteraction, Visualizer {
...
}
I think that the main point in the Interface Segregation Principle is that the interfaces should be client-specific. They should basically "summarize" the functions that are required by a certain client, for a certain task.
To put it that way: The issue is to strike the right balance between the extremes that I sketched above. When I'm trying to figure out interfaces and their relationships (mutually, and in terms of the classes that implement them), I always try to take a step back and ask myself, in an intentionally naïve way: Who is going to receive what, and what is he going to do with it?
Regarding your example: When all your clients always need the functionality of Interface1
and Interface2
at the same time, then you should consider either defining an
interface Combined extends Interface1, Interface2 { }
or not have different interfaces in the first place. On the other hand, when the functionalities are completely distinct and unrelated and never used together, then you should wonder why the single class is implementing them at the same time.
At this point, one could refer to another principle, namely Composition over inheritance. Although it is not classically related to implementing multiple interfaces, composition can also be favorable in this case. For example, you could change your class to not implement the interfaces directly, but only provide instances that implement them:
class Example {
Interface1 getInterface1() { ... }
Interface2 getInterface2() { ... }
}
(Note: It looks a bit odd in this Example
(sic!), but depending on the complexity of the implementation of Interface1
and Interface2
, it can really make sense to keep them separated)
Usually, many, client-specific interfaces are fine, and somewhat part of the Interface segregation principle (the "I" in SOLID). Some more specific points, on a technical level, have already been mentioned in other answers.
Particularly that you can go too far with this segregation, by having a class like
class Person implements FirstNameProvider, LastNameProvider, AgeProvider ... {
@Override String getFirstName() {...}
@Override String getLastName() {...}
@Override int getAge() {...}
...
}
Or, conversely, that you have an implementing class that is too powerful, as in
class Application implements DatabaseReader, DataProcessor, UserInteraction, Visualizer {
...
}
I think that the main point in the Interface Segregation Principle is that the interfaces should be client-specific. They should basically "summarize" the functions that are required by a certain client, for a certain task.
To put it that way: The issue is to strike the right balance between the extremes that I sketched above. When I'm trying to figure out interfaces and their relationships (mutually, and in terms of the classes that implement them), I always try to take a step back and ask myself, in an intentionally naïve way: Who is going to receive what, and what is he going to do with it?
Regarding your example: When all your clients always need the functionality of Interface1
and Interface2
at the same time, then you should consider either defining an
interface Combined extends Interface1, Interface2 { }
or not have different interfaces in the first place. On the other hand, when the functionalities are completely distinct and unrelated and never used together, then you should wonder why the single class is implementing them at the same time.
At this point, one could refer to another principle, namely Composition over inheritance. Although it is not classically related to implementing multiple interfaces, composition can also be favorable in this case. For example, you could change your class to not implement the interfaces directly, but only provide instances that implement them:
class Example {
Interface1 getInterface1() { ... }
Interface2 getInterface2() { ... }
}
(Note: It looks a bit odd in this Example
(sic!), but depending on the complexity of the implementation of Interface1
and Interface2
, it can really make sense to keep them separated)
answered 12 hours ago
Marco13Marco13
42k855108
42k855108
This is the correct answer. The interface is built for the contract that the client code needs fulfilled. If the client code reasonably expects to be able to call someInterface1Method AND someInterface2Method, then that is a new contract. From wikipedia on ISP: "no client should be forced to depend on methods it does not use." and "clients will only have to know about the methods that are of interest to them."
– Xtros
7 hours ago
add a comment |
This is the correct answer. The interface is built for the contract that the client code needs fulfilled. If the client code reasonably expects to be able to call someInterface1Method AND someInterface2Method, then that is a new contract. From wikipedia on ISP: "no client should be forced to depend on methods it does not use." and "clients will only have to know about the methods that are of interest to them."
– Xtros
7 hours ago
This is the correct answer. The interface is built for the contract that the client code needs fulfilled. If the client code reasonably expects to be able to call someInterface1Method AND someInterface2Method, then that is a new contract. From wikipedia on ISP: "no client should be forced to depend on methods it does not use." and "clients will only have to know about the methods that are of interest to them."
– Xtros
7 hours ago
This is the correct answer. The interface is built for the contract that the client code needs fulfilled. If the client code reasonably expects to be able to call someInterface1Method AND someInterface2Method, then that is a new contract. From wikipedia on ISP: "no client should be forced to depend on methods it does not use." and "clients will only have to know about the methods that are of interest to them."
– Xtros
7 hours ago
add a comment |
The problem you describe often comes about through over-zealous application of the Interface Segregation Principle, encouraged by languages' inability to specify that members of one interface should, by default, be chained to static methods which could implement sensible behaviors.
Consider, for example, a basic sequence/enumeration interface and the following behaviors:
Produce an enumerator which can read out the objects if no other iterator has yet been created.
Produce an enumerator which can read out the objects even if another iterator has already been created and used.
Report how many items are in the sequence
Report the value of the Nth item in the sequence
Copy a range of items from the object into an array of that type.
Yield a reference to an immutable object that can accommodate the above operations efficiently with contents that are guaranteed never to change.
I would suggest that such abilities should be part of the basic sequence/enumeration interface, along with a method/property to indicate which of the above operations are meaningfully supported. Some kinds of single-shot on-demand enumerators (e.g. an infinite truly-random sequence generator) might not be able to support any of those functions, but segregating such functions into separate interfaces will make it much harder to produce efficient wrappers for many kinds of operations.
One could produce a wrapper class that would accommodate all of the above operations, though not necessarily efficiently, on any finite sequence which supports the first ability. If, however, the class is being used to wrap an object that already supports some of those abilities (e.g. access the Nth item), having the wrapper use the underlying behaviors could be much more efficient than having it do everything via the second function above (e.g. creating a new enumerator, and using that to iteratively read and ignore items from the sequence until the desired one is reached).
Having all objects that produce any kind of sequence support an interface that includes all of the above, along with an indication of what abilities are supported, would be cleaner than trying to have different interfaces for different subsets of abilities, and requiring that wrapper classes make explicit provision for any combinations they want to expose to their clients.
add a comment |
The problem you describe often comes about through over-zealous application of the Interface Segregation Principle, encouraged by languages' inability to specify that members of one interface should, by default, be chained to static methods which could implement sensible behaviors.
Consider, for example, a basic sequence/enumeration interface and the following behaviors:
Produce an enumerator which can read out the objects if no other iterator has yet been created.
Produce an enumerator which can read out the objects even if another iterator has already been created and used.
Report how many items are in the sequence
Report the value of the Nth item in the sequence
Copy a range of items from the object into an array of that type.
Yield a reference to an immutable object that can accommodate the above operations efficiently with contents that are guaranteed never to change.
I would suggest that such abilities should be part of the basic sequence/enumeration interface, along with a method/property to indicate which of the above operations are meaningfully supported. Some kinds of single-shot on-demand enumerators (e.g. an infinite truly-random sequence generator) might not be able to support any of those functions, but segregating such functions into separate interfaces will make it much harder to produce efficient wrappers for many kinds of operations.
One could produce a wrapper class that would accommodate all of the above operations, though not necessarily efficiently, on any finite sequence which supports the first ability. If, however, the class is being used to wrap an object that already supports some of those abilities (e.g. access the Nth item), having the wrapper use the underlying behaviors could be much more efficient than having it do everything via the second function above (e.g. creating a new enumerator, and using that to iteratively read and ignore items from the sequence until the desired one is reached).
Having all objects that produce any kind of sequence support an interface that includes all of the above, along with an indication of what abilities are supported, would be cleaner than trying to have different interfaces for different subsets of abilities, and requiring that wrapper classes make explicit provision for any combinations they want to expose to their clients.
add a comment |
The problem you describe often comes about through over-zealous application of the Interface Segregation Principle, encouraged by languages' inability to specify that members of one interface should, by default, be chained to static methods which could implement sensible behaviors.
Consider, for example, a basic sequence/enumeration interface and the following behaviors:
Produce an enumerator which can read out the objects if no other iterator has yet been created.
Produce an enumerator which can read out the objects even if another iterator has already been created and used.
Report how many items are in the sequence
Report the value of the Nth item in the sequence
Copy a range of items from the object into an array of that type.
Yield a reference to an immutable object that can accommodate the above operations efficiently with contents that are guaranteed never to change.
I would suggest that such abilities should be part of the basic sequence/enumeration interface, along with a method/property to indicate which of the above operations are meaningfully supported. Some kinds of single-shot on-demand enumerators (e.g. an infinite truly-random sequence generator) might not be able to support any of those functions, but segregating such functions into separate interfaces will make it much harder to produce efficient wrappers for many kinds of operations.
One could produce a wrapper class that would accommodate all of the above operations, though not necessarily efficiently, on any finite sequence which supports the first ability. If, however, the class is being used to wrap an object that already supports some of those abilities (e.g. access the Nth item), having the wrapper use the underlying behaviors could be much more efficient than having it do everything via the second function above (e.g. creating a new enumerator, and using that to iteratively read and ignore items from the sequence until the desired one is reached).
Having all objects that produce any kind of sequence support an interface that includes all of the above, along with an indication of what abilities are supported, would be cleaner than trying to have different interfaces for different subsets of abilities, and requiring that wrapper classes make explicit provision for any combinations they want to expose to their clients.
The problem you describe often comes about through over-zealous application of the Interface Segregation Principle, encouraged by languages' inability to specify that members of one interface should, by default, be chained to static methods which could implement sensible behaviors.
Consider, for example, a basic sequence/enumeration interface and the following behaviors:
Produce an enumerator which can read out the objects if no other iterator has yet been created.
Produce an enumerator which can read out the objects even if another iterator has already been created and used.
Report how many items are in the sequence
Report the value of the Nth item in the sequence
Copy a range of items from the object into an array of that type.
Yield a reference to an immutable object that can accommodate the above operations efficiently with contents that are guaranteed never to change.
I would suggest that such abilities should be part of the basic sequence/enumeration interface, along with a method/property to indicate which of the above operations are meaningfully supported. Some kinds of single-shot on-demand enumerators (e.g. an infinite truly-random sequence generator) might not be able to support any of those functions, but segregating such functions into separate interfaces will make it much harder to produce efficient wrappers for many kinds of operations.
One could produce a wrapper class that would accommodate all of the above operations, though not necessarily efficiently, on any finite sequence which supports the first ability. If, however, the class is being used to wrap an object that already supports some of those abilities (e.g. access the Nth item), having the wrapper use the underlying behaviors could be much more efficient than having it do everything via the second function above (e.g. creating a new enumerator, and using that to iteratively read and ignore items from the sequence until the desired one is reached).
Having all objects that produce any kind of sequence support an interface that includes all of the above, along with an indication of what abilities are supported, would be cleaner than trying to have different interfaces for different subsets of abilities, and requiring that wrapper classes make explicit provision for any combinations they want to expose to their clients.
answered 11 hours ago
supercatsupercat
56.5k2117150
56.5k2117150
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54184354%2fhow-do-i-avoid-breaking-the-liskov-substitution-principle-with-a-class-that-impl%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
15
I wouldn't add the check. If I had to have both interfaces in play in a single scope I'd make the compile time type Example, not Interface1.
– duffymo
15 hours ago
1
You definitely don't need to cast in this situation. It should always be a last resort. Probably more than 90% of casts are simply a result of bad design.
– Michael
15 hours ago
6
create a third interface which extends those 2 you've mentioned and use the former throughout your code. or use generics to be more forgiving:
public <T extends Interfac1 & Interface2> void doSomething(T t)
– Lino
15 hours ago
5
Can't you use
Example example = new Example();
?– Andy Turner
15 hours ago
Given that casts are a reasonable feature of the Java language, we can't answer these questions without knowing the purpose of the class and interfaces and why you want to cast.
– Matt Timmermans
15 hours ago