Simple circular dependency between three classes

Question

I have this basic design with a circular dependency. Is there any solution for this? The problem is that a Machine cannot be created if a Model for that Team has been submitted.

Answer 1

Design

From a design point of view, circular dependencies are usual business:

• A team works with models to build or test machines. There is an ambiguity since many is not defined in the UML notation. It suggests a multiplicity of either 0..* or 1..*.
• Conversely, every machine is build/tested based on a single model and every machine is build/tested by one team. Here, 1 unambiguously means exactly one.
• In absence of any constraints, a machine can be build by a team based on a model of another team.

Implementation

You'll have to cope with circular dependencies, since each class has to know about the others. The solution depends on the language: there are already plenty of them on StackOverflow. Search for the tag circular-dependency combined with your favorite language. In general, with reference semantic (i.e. java object, C++ pointer or reference, C# class object) it is no particular difficulty.

Instantiation

You cannot enforce all the associations, if they are all mandatory at the same time. It's the circularity issue of the chicken and the egg, since there would always be a mandatory associated object missing for whatever you want to instantiate.

Possible solutions:

1. Relax the constraints: If many is understood as 0..*, you could create a team without having neither a model nor a machine. You could then create a model associated with the team, but with no machine yet. Finally, you could create the machine for the both other elements. This appears to me the most natural solution.

2. Create the egg first: Allow the creation of the objects without having all the associations from the start. Make a chicken out of the egg: use a variant of the builder pattern to make sure the that after the build process, all the mandatory constraints/associations are consistent.

3. Decouple time and constraints: Design explicitly the life-cycle of your objects, and enforce contraints in their behavior with the state pattern. You can then keep the object in an unusable state "Not ready" until all the mandatory associations are provided. But in your situation, this seems like a bulldozer rolling over a fly, and I'd still strongly suggest to consider optinon 1.