Tukukkk

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();

}

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.

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).

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

    }

}

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)

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:

1. Produce an enumerator which can read out the objects if no other iterator has yet been created.




2. Produce an enumerator which can read out the objects even if another iterator has already been created and used.




3. Report how many items are in the sequence




4. Report the value of the Nth item in the sequence




5. Copy a range of items from the object into an array of that type.




6. 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.