I am trying to determine what the best way to represent a Child is. The environment is a bit different, but I'll try and explain to give some context.
We provide custom implementations of our software for different clients. Therefore, we have a "core" package that every implementation depends on, as well as many "auxiliary packages" that can be used in a client implementation to provide some of the custom behavior. These "auxiliary packages" are self contained units of code that provide a specific feature, and depend on our "core" package.
The problem I am trying to solve is how to map a AuxChild in an "auxiliary package"? The CoreParent belongs in "core", and the AuxChild is a one-to-one with the CoreParent. However, I don't want to map the AuxChild to the CoreParent as not every client implementation will use AuxChild.
The client implementations can extend the CoreParent to add additional metadata (properties). I would like to AuxChild to be mapped in the ClientParent, as the AuxChild is a group of additional metadata, and would like for AuxChild to share the same ID ad CoreParent. The problem is that AuxChild isn't aware of the ClientParent.
Here's some code to maybe make things clearer:
in core package:
in auxiliary package:
in client implementation:
One way of doing this is to make a class "AuxParent extends CoreParent". Then in the client implementation, do "ClientParent extends AuxParent". The problem with this is when I have multiple "auxiliary packages" depended upon in a client implementation, as java doesn't support multiple inheritance.
Maybe interfaces is a better way to implement this?
Any thoughts would be greatly appreciated.
I wish to win the lottery. I wish for a lovely piece of pie. And I wish for a tiny ad: