OOP Design: relationship between entity classes

Question

I have at first sight a simple issue but can't wrap my head around on how to solve. I have an abstract class Compound. A Compound is made up of Structures. Then there is also a Container which holds 1 Compound.

A "special" implementation of Compound has Versions. For that type of Compound I want the Container to hold the Versionof the Compound and not the Compound itself.

You could say "just create an interface Containable" and a Container holds 1 Containable. However that won't work. The reason is I'm creating a framework and the main part of that framework is to simplify storing and especially searching for special data type held by Structure objects. Hence to search for Containers which contain a Compound made up of a specific Structure requires that the "Path" from Containerto Structure is well defined (Number of relationships or joins).

I hope this was understandable. My question is how to design the classes and relationships to be able to do what I outlined.

EDIT:

Kind of translation issue. with version i did not mean in terms of "versioning" but more in terms of "different variety" but fundamentally the same. There is no active / inactive. All are active.

EDIT 2:

Also note that these classes are entity classes and hence complex inheritance and hierarchies can be problematic.

EDIT 3:

Just don't see how either pattern (Composite, decorator) can work. I tried but the problem is the "path traversal", eg. implementing it in the context of Spring-data and QueryDSL.

I've created Class diagramm with comments that might help to understand the issue. Batch = Version.

Answer 1

... to search for Containers which contain a Compound made up of a specific Structure requires that the "Path" from Container to Structure is well defined (Number of relationships or joins).

Not if you are asking the container if it has such a structure yes or no, then only the container needs to know the path. You can keep it an implementation detail in such a case.

Implement a container class for version-less compounds, and an implementation for version-ed compounds. You indirectly traverse the structures through delegation.

Answer 2

Can you have the special Compound implementation pass invocations of its Compound methods to its active Version? That way the Container wouldn't know that it has a special Compound.

Answer 3

If I understand correctly, Compound is an abstract class. One implementation of a compound doesn't have Versions but another does. As @SteveEmmerson suggested, giving Compound an ActiveVersion property would solve this design problem.

The option I prefer is to apply the Composite pattern. In this design, the implementation of Compound (say, VersionedCompound) would be responsible for which Version's data to present when it's treated like a Compound.

I prefer it because this design is additive, in other words, it does not require refactoring the Compound class.

Answer 4

There are so many ways to accomplish variation in code structures and function.

In this case, if their are no functions that operate differently for a versioned Compound than a non-versioned Compound, then inheritance or some design pattern would be overkill.

How about just an attribute "version"? For simple compounds, the version could be "none" or 0 or 1, whatever makes most sense for the way you use it.

If for some reason the actual functions on Compound need to be implemented differently, then you do want polymorphism. In that case, I think neontapirs description of using the Composite pattern is a good direction.

How do you expect the client code to use a Compound versus a Versioned Compound?

Are these like isotopes, or left-handed/right-handed sugars?

Answer 5

This problem can be tackled using Decorator pattern. Just keep Container related to Compound, and turn Version into a decorator of Compound.

Using the reference diagram here, your problem could be mapped this way:

• Component = Compound
• ConcreteComponent = concrete Compound that holds Structures
• Decorator = Version Concrete
• Decorator = version of models or packs of extras

Hope it helps.

Answer 6

The solution I used is this:

And to reference the image in the question, a Batch extends Containable.