How To Avoid Dependencies between Modules

Question

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?

• Doc Brown: Why does ExtendedUpload not just inherit from Upload? Seems the most natural solution to me. And concerning the GUI: somehow you need to provide a GUI extension for those optional fields. If that extension shall nicely integrate into the GUI without the optional fields, the latter has to be designed with that optional fields at least in mind. So maybe your customers suggestion is actually not so bad, as long as you don't get cyclic dependencies.
• Steffi S.: @DocBrown Extending, yes, that's why I named it ExtendedUpload, because that was my first guess as well (even though I find delegating to be a bit more elegant). I added to the question to show that there is an API layer the entities get mapped to, and so it's a bit more complicated than just adding fields to the entity.
• Doc Brown: I don't get it. If your API uses an "Upload" class, it will be able to process ExtendedUpdload2 objects as well. And I don't see why you have to "copy" all API classes, why not just extend them at the few places where the extension may have relevance. Can you give a more detailed example for the problems you have with the API?
• Steffi S.: @DocBrown Because the API does not use the Upload class. It uses the class UploadValue, which looks almost the same (but without the server dependencies). Which means we would need an ExtendedUploadValue. Which means we would need to implement all the server stuff anew, since there are new values and entities to map from and to.
• Doc Brown: Is this some Java beans stuff? Seems you have more general problems in your code base when extensions by adding one inherited class causes you so much hassle.

Answer 1

If I got you right, your situation is as follows:

• you have customers who are happy with the vanilla Upload class
• at least one other needs an extension
• you want to avoid the creation of an ExtendedUpload class 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, where UploadField is a class residing in module U, looking similar to Field, maybe reduced to the attributes you really need from Field. The upside is that you avoid the dependency, and that UploadField has its own "lifecycle", independent from "Field". The downside is that this may result in some code duplication, and, well, UploadField has 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.

• Ext3h: An appropriate type for X would be Pair<String, String> with the pair denoting data type and serialized representation, that way U needs zero additional knowledge about the data stored. That structure is also usable by other components which would want to store data inside. As an refinement, go as far as to use a HashMap instead of a List, as that would probably be the next customer request.

Answer 2

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.

• Doc Brown: I guess that is not what the OP wants to know, he seems to be after a solution which avoids the class Upload to be extended by a List<WhateverTypeGoesHere> at all.
• dodev: @doc-brown, I see. I didn't catch the fact that the OP, doesn't want to change the module F at all. Then your solution (inherit from Upload) is the way to go.
• Doc Brown: I am not sure if what I wrote is really a solution for the OP, it is actually not so different from what he suggested and may not solve the problems with the manager and GUI classes. But as long as the OP does not gives any additional information, I don't think I can give a real answer.
• Steffi S.: That's a good suggestion to decouple the modules, but as you guessed, it's more about avoiding the List<Field> altogether for the actual modules and tack them on later on for only the customer who needs them.

Answer 3

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.

Answer 4

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.