jmut wrote:could you give a simple example of how this could be useful?
cause I kind of see it pointless to this point...and would consider it poor design more than anything else.
thanks.
Poor design how? Is it poor design to extend a class? It's the same principle.
The reason I need it is that I'm doing something Java-esque and creating Event objects and EventListener objects.
Now, in Java (Swing/AWT) you have for example a Action event and in order to respond to the Action event you need to have an object implementing the AcionListener interface and you bind that to the swing component it acts on.
In my library I have similar triggers like Send events and SendListener objects to respond to them. But while I need a SendListener to implement the appropriate interface it also needs to implement some things from the BeforeSend event listener. I could easily force the developer to implement both interfaces but I'd rather it was transparent to the developer how the underbelly is structured since it's clearer to Joe Bloggs when he write an event listener to just implement the interface for that listener rather than remembering the specific case of where several interfaces are needed.
I often have empty interfaces of abstract classes *purely* for identity among a group of objects too. Now that I know is probably bad design but I do it anyway
