Take the 2-minute tour ×

I have two interfaces, HasClickHandlers and DoesFancyFeedback. Then I have some UI objects that implement both interfaces - for example, a Button that implements both has click handlers and also does fancy feedback.

In my code that's declaring Buttons, I don't want to actually say Button because maybe later I'll want it to be, I dunno, an Image that has click handlers and does fancy feedback. So instead of being specific and saying something like:

Button saveButton = aButtonIPassedIn;

I want to say,

{HasClickHandlers + DoesFancyFeedback} clickyFeedbackThing = aThingIPassedIn;

I want the compiler to require that aThingIPassedIn implement both HasClickHandlers and DoesFancyFeedback.

I could create an interface that extends those two interfaces, and use that. Is there any easier/less verbose way?

share|improve this question
You can theoretically do this with generics, I think -- place a constraint on the argument that it must implement both interfaces. However it's been a while since I've used Java generics, so my memory might be a bit tainted by .NET generics. –  cdhowie Nov 26 '10 at 22:35
Any specifics (hah) on how to accomplish this would be great! –  Riley Lark Nov 26 '10 at 22:38
add comment

5 Answers

up vote 17 down vote accepted

I do not think that there is a better way to do what you want. I just wanted to suggest you to do the following. You can create method (let's call it foo) that accepts argument that requires 2 interfaces:

<T extends HasClickHandlers & DoesFancyFeedback> void foo(T arg);

Please pay attention on one ampersand between 2 your interfaces.

share|improve this answer
Whoa, who knew!? After this, it would always be safe to cast arg to either HasClickHandlers or DoesFancyFeedback, right? This would be way easier than making a composite interface for every combination of interfaces I could ever want. –  Riley Lark Nov 26 '10 at 22:40
@Riley: You don't have to cast it in this case, simply call the methods on it. –  thejh Nov 26 '10 at 22:42
Ah, of course. This is great! –  Riley Lark Nov 26 '10 at 22:43
I have created a sample for this approach: pastebin.com/xpeBvAQ1 –  OscarRyz Nov 26 '10 at 22:54
Just came across this question. @Riley: I guess you're talking about a method of the Display interface implemented by your view class, right? What I don't see is how you get the instance implementing HasClickHandlers and DoesFancyFeedback in your presenter code. Something like <T extends HasClickHandlers & DoesFancyFeedback> T getFancy() would be needed in the Display interface I guess. For the implementation of this method I don't see a solution without casting. Can you tell me how you'd achieved this? Thanks. –  z00bs Jan 18 '11 at 10:06
show 3 more comments

You may try to use generics:

public < T extends HashClickHandlers & DoesFancyFeedback > void foo (
        T aThingIPassedIn
    aThingIPassedIn.addClickHandler( );
    aThingIPassedIn.doFancyFeedback( );
share|improve this answer
A great way to declare a parameter - is there any way to declare a field or other variable like this? –  Riley Lark Nov 26 '10 at 22:42
add comment

No, there is no such a thing in Java.

You would have to use the option you mention of creating a third interface. That way you'll be explicitly declaring your intention to use a new type.

Is not that verbose after all ( considering the alternative ), because you would just type:

public interface FancyWithHandler 
       extends HashClickHandlers , DoesFancyFeedback {} 

You don't need to include the methods. And then just use it:

FancyWithHandler clickyFeedbackThing = aThingIPassedIn;

While the generic option looks interesting, probably at the end you'll end up creating a much more verbose thing.

share|improve this answer
OP said: "I could create an interface that extends those two interfaces, and use that. Is there any easier/less verbose way?" –  thejh Nov 26 '10 at 22:34
I miss that part, I have changed my answer. –  OscarRyz Nov 26 '10 at 22:46
add comment

Although that would be ugly, you could propably make it an Object and cast it. For the calling method, it would be the easiest way.

share|improve this answer
add comment

I wouldn't want a Button to implement any of those interfaces. What you're describing sounds more like the province of an event listener. Better to have the listener implement plain and fancy click handlers, and pass the listener into the Button or UI component. It's more of a delegation model that keeps processing out of the UI components and in separate classes that you can change at will.

share|improve this answer
You wouldn't want a Button to implement HasClickHandlers? This isn't processing, this is user interface - DoesFancyFeedback in this case is "show a twirling loading icon next to the button text," and HasClickHandlers is "tell me when the user clicks this button." After all, what would the listener you propose attach to if not the Button itself? –  Riley Lark Nov 26 '10 at 22:58
What is HasClickHandlers doing? Just a true/false to indicate whether something is registered? –  duffymo Nov 27 '10 at 0:01
add comment

Your Answer


