So I've got something working that seems a little hokie to me, and I was wondering if the design is violating any best practices. I can elaborate more on why the design exists this way if need be, but for now, this is the situation:
I've got a single base interface, FunI. Then, there is another interface, MoreFunI, that extends the first interface (FunI). There is also an abstract class, AbsFun, that implements a couple of methods in the base interface (FunI). Finally, there is a concrete class, LotsoFun, that both extends AbsFun and implements MoreFunI. Also, there are no clashing method signatures between MoreFunI and AbsFun. The whole set up works fine, and doesn't produce any problems at compile time.
However, like I said, my concern is that I'm afraid that the design is violating some best practices, since there isn't a nice single chain of inheritance, and possibly asking for bugs to pop up in the future.
I can not immediately give an example of where I have done something like this, but reading your example I can't say that anything jumps out at me as wrong. It seems you are more asking an object modeling question, i.e., does this interface design and class implementation make sense for the problems I am trying to solve and is there a different way that it should be modeled to support the solution.
If you have separated the desired behavior you wish to see isolated into FunI and MoreFunI and it makes sense as separated then I think you are ok.
Douglas Rapp wrote:However, like I said, my concern is that I'm afraid that the design is violating some best practices
Not that I can see. I think the only question I would ask myself is whether LotsOFun shouldn't actually be an interface that extends the other two, and then hang a LotsOFunImpl class off that (although I suggest you find a better name); but only you can answer that one.
since there isn't a nice single chain of inheritance, and possibly asking for bugs to pop up in the future.
I think it's far more likely that bugs (or even more likely - brittleness) are likely to result from having long chains of inheritance.
extends is a bit old hat these days, and programmers often look for more flexibility using composition (Google it), coupled with sets of interfaces.
Bats fly at night, 'cause they aren't we. And if we tried, we'd hit a tree -- Ogden Nash (or should've been).
Articles by Winston can be found here