I have three classes of object, most of which must implement two out of three interfaces. The interfaces look like this:
Most of my classes must implement two of the three above, such that my class definitions (before implementing the necessary methods) would look like this:
That works fine, but I am wondering if pairing the interfaces into subinterfaces is a defensible methodology. For example, all classes that act like Producer must implement both the Source and Sender interfaces. And all classes that act like Relayer must implement the Sender and BlackHole interfaces. I could define two subinterfaces like this:
I could then define my classes like this:
Within the class definitions, it makes no difference, as I will have to implement the same methods either way. But it seems more self-documentary to create the subinterfaces from their parent interfaces and name them in ways that reflect what the classes that implement them must actually do.
Is this a good idea, obfuscatory, or something else?
In the other disciplines, we rise by standing on each others' shoulders. In computer science, we do it by standing on each others' toes.
You only seem to have considered the definition of your interfaces so far. What about their use ? If you are going to need variables that act as both BlackHole and Sender at the same time, then you are going to need the Relayer interface or you will end up with code with a lot of casting in it.
Stevens Miller wrote:That works fine, but I am wondering if pairing the interfaces into subinterfaces is a defensible methodology.
Seems fine to me. What I'm not so sure about is whether Producer, Relayer and Consumer are actually classes; they look much more like interfaces to me as well.
I think, if I was doing this, I'd then be tempted to create skeleton implementations of each of them with abstract classes (AbstractProducer, AbstractRelayer and AbstractConsumer?) that cover the majority of cases you're likely to need. That would then save you the trouble of coming up with "interface names" for interfaces that basically define the same types as your classes currently do.
However, it's only one possibility; there are plenty of others.
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
Stevens Miller wrote:Thanks, folks! Just what I needed in the way of feedback.
I work alone, so there's no one in the next cube to talk to about things like this (because, well, there's no "next cube" here).
Glad we could help. Welcome to JavaRanch, and feel free to think of us as your "next cube".