API Design Question

[Scott]

Hi,

I'm designing an API of container objects such that:

there is an abstract ContainerObject,

ContainerObjectA extends ContainerObject, and stores:
ContainerObjectB, which extends ContainerObject, and stores:
ContainerObjectC, which extends ContainerObject, and stores:
ContainerObjectD, which also extends ContainerObject.

However, I wish to make ContainerObjectD an abstract class that must be
extended by the API user to allow for customization of the final level of
containment. This may seem a little odd, but the data is organized in
such a way that the upper levels of containment objects will be identical,
but the lower objects will differ (i.e. ContainerObjectD will contain
one or more customizable objects). So, my question is, how do I handle
ContainerObjectC? - it will only ever access the interfaces in
ContainerObjectD defined by the abstract ContainerObject, not any of the
extended elements. But, I won't know what the name or location of the
extended object of ContainerObjectD will be. Do I just leave it to the
API user to edit ContainerObjectC and insert the name of the new extended
class, or is there a way to approach this is a more structured manner?
Also, can an abstract class be extended by an abstract class? Should I
use an interface instead? That will still leave the problem of how I
should refer to the abstract class within a non-abstract one. I hope this
makes sense, and thanks for any advice!

Best Regards,

Scott

 

[rkm]

You lost me when you said ContainerObjectC needs to know
about the new extended class. I thought only
ContainerObjectD needed to know about that.
Rick

 

[Scott]

You lost me when you said ContainerObjectC needs to know
about the new extended class. I thought only
ContainerObjectD needed to know about that.
Rick

Thanks for the reply.

Actually, ContainerObjectD is abstract, so the new extended object
will essentially replace ContainerObjectD, and will be the object that
ContainerObjectC contains (!) So, ContainerObjectC will have to have
knowledge of the extended class.

Scott

 

[xarax]

Thanks for the reply.

Actually, ContainerObjectD is abstract, so the new extended object
will essentially replace ContainerObjectD, and will be the object that
ContainerObjectC contains (!) So, ContainerObjectC will have to have
knowledge of the extended class.

Scott

No, it just needs knowledge of the ContainerObjectD class/interface.
The concrete implementation can be anything that extends the class
or implements the interface that you specify as ContainerObjectD.

An interface is probably better than an abstract class in this
case.

 

[Scott]

Basic answers first:

+ An abstract class can extend an abstract class (or a non-abstract class).

+ You don't reveal enough of what you are doing to tell if you should use an interface,
but it is likely.

Thanks for the reply. I've been doing a bit of research and
re-thinking, and I'm going to do the whole thing over again with an
interface. It does seem to be the best route. Thanks again!

Scott