We have two modules, lets call them U and F.
Module U has entities like that:
class Upload {
Long id;
User uploadedBy;
Date uploadedAt;
}
Module F has entities like that:
class Field {
Long id;
String displayName;
Type type;
}
And both have the typical manager beans with create, edit, delete and some GUI depending on them.
So now what one customer wants to have is for us to add to the entites of module U so they will look like that:
class Upload {
// fields as above
List<Field> fields;
}
I don’t think that’s the best idea, because it would create a dependency between F and U that is not necessary for most customers. So now we are trying to find a good architecture that allows us to model what the customer wants without creating dependencies.
One thing that came to mind was to create a Module E with entities like that:
class ExtendedUpload1 {
Upload upload;
List<Field> fields;
}
// or...
class ExtendedUpload2 extends Upload {
List<Field> fields;
}
So only that module will have dependencies to both F and U, and both F and U can live separately. But we have an API in between GUI and server, meaning separate values classes and interfaces both sides work with. And while we can inject additional functionality to both GUI and server, dynamically extending the API is the actual problem. We would need to copy all the API classes to work with the new values.
What architectural patterns apply to that use case? How could we solve the problem elegantly?
7
If I got you right, your situation is as follows:
- you have customers who are happy with the vanilla
Uploadclass - at least one other needs an extension
- you want to avoid the creation of an
ExtendedUploadclass because it causes you too much hassle (for what reason ever) - if possible, you want to avoid the introduction of a dependency between F and U
I think in this situation, it is the best to modify the Upload class, even if that is not your preferred solution. So some variant of
class Upload {
// fields as above
List<X> extensionFields;
}
is probably the best way to go. For customers who don’t need the extensions, extensionFields keeps just beeing an empty list. So the “default customer” is just a special case of the “extended customer” (you have to implement this either), which is naturally included by the empty list, so there should be no explicit handling necessary for the “default customer” when you implement that carefully.
What remains is to choose a type for X:
-
either you go with your first approach,
X=Field. Only you know how much of a problem it is when you live with that dependency. -
or you set
X=FieldInterface, as @dodev suggested. That avoids the direct coupling, in fact it shifts the coupling from compile time to run time -
or you set
X=UploadField, whereUploadFieldis a class residing in module U, looking similar toField, maybe reduced to the attributes you really need fromField. The upside is that you avoid the dependency, and thatUploadFieldhas its own “lifecycle”, independent from “Field”. The downside is that this may result in some code duplication, and, well,UploadFieldhas its own “lifecycle”. If an “UpdateField” must be alwas identical to “Field”, you now have to maintain two classes and keep them in-sync.
So pick your choice, none of the solutions is perfect, this is a trade-off only you can solve.
1
If I understand correctly your question, you don’t want to mention the exstince of module F in the code of module U, making them loosely coupled, i.e. the module F can be replaced some times in the future.
In that case the first one that comes to mind:
Program to an interface, not an implementation – GoF
Basically Upload::fields can be of type List<FieldInterface> and the type Field
can implement the FieldInterface. That way U doesn’t need to know nothing about F, the only thing on which U is dependent on is the abstract interface FieldInterface.
4
If the language you use supports generics, what about something like the following:
class Upload<ExtendedData> {
Long id;
User uploadedBy;
Date uploadedAt;
List<ExtendedData> data;
}
This way, Upload and Field can live in different namespaces / modules, but can be combined in the client-specific case where the user wants to Upload Field instances.
Program to an interface is usually used for decoupling. It doesn’t really matter how the interface is implemented. The modules F and U can have their own implementations.
If you need complete decoupling, move the interface in a new module I, where you can define the API. In this way, F and U are consumers for the I module and they are still independent of each other.