I have read multiple websites on this topic but none of them gave me a 'good' solution for the problem I am having. The problem is described in the following (related) questions:
- How do I couple the UI package with the rest of the system without too much coupling with classes inside the other packages (I am thinking of the facade pattern).
- I am having a lot of single instance classes but I don't want to use the Singleton Pattern to force the single instance. In some cases I need access to those classes in other packages.
See the figure below for a (simplified) class and package diagram of the system. I am having a class ProtocolParser (not the real name) that parses incoming data and raises events when certain packages are received. The events are handled by the AnchorManager and the TagManager. Those classes do almost the same thing. When the event is received they look in their list of Anchors or Tags if they find a Anchor or Tag with the same id they update it with new data otherwise they create a new Anchor or Tag. I also have class TrackingDeviceManager this class is responsible for keeping a list of all TrackingDevices in the system (so for example the UI can show a list of them).
It is not really useful to have multiple instances of the classes TrackingDeviceManger, AnchorManager and TagManager since they need to keep track of all the TrackingDevices, Anchors or Tags in the system. So I could potentially make them singletons. But I don't think the singleton pattern is the right way to go here.
So I am thinking to implement a TrackingFacade (singleton and a facade) this class will create instances of the three classes and initialize them. It also exposes some public methods and events so other classes in other packages can consume those. But I am wondering if this is a good approach. Or should I rethink my design?
Class diagram (simplified)
Package diagram
Best Answer
Regarding singletons
None of the classes pictured here should be a singleton.
The only class which should be a singleton is the main application class, which instantiates the two major classes that we see here: the "Tracking" class, which is your application logic (domain logic) and the "UI" class, which is your UI.
And just so as to make sure we are on the same page, by "Singleton" I mean a class which has a private constructor and has a
public static final TrackingApplication INSTANCE = new TrackingApplication();member.Regarding facades
The need you have discovered is actually that which the MVC and MVVM architectural patterns were invented to address.
Without too much jargon, what you have to the left of your "TrackingFacade" box is the classes that comprise your "model". What you want is an intermediate class between your model and your UI code which offers a uniform "presentation" of your model so that your UI can make use of it instead of being concerned with the details of your model. Also, in this intermediate class you are likely to add "business" logic (application logic, domain logic) which receives commands from the UI and performs actions on your model. (That's why it is not just a facade.)
In MVC this intermediate class can roughly be thought of as the "Controller", while in MVVM it corresponds to the "ViewModel". I would recommend reading up on these architectural patterns.