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:

  1. 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).
  2. 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 Class diagram (simplified)

Package Diagram Package diagram

  • 1
    What do you mean by "coupling with classes inside the other packages"? What other packages? – Mike Nakis Dec 10 '15 at 19:43
  • @MikeNakis For example the classes shown in the Tracking package. TrackingWindow could have a relations with TrackingDeviceManager, AnchorManager and TagManager but using a Facade I can prevent this (I think) – Faas Dec 10 '15 at 20:38

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.

  • We are one the same page concerning the Singleton. So for every package in the system I create one or more Controller classes that expose some functionality of the package to other classes. Now my question remains how can other packages get to the Controller of let say the Tracking pacage (TrackingController) without making al the controllers Singletons. – Faas Dec 10 '15 at 21:45
  • Usually nobody invokes the Controller. The controller invokes model entities to get/set stuff from them, and the controller invokes the GUI to get/set stuff to it. Also, if you have multiple controllers, they still don't talk to each other. A controller modifies a model entity, the model entity raises a notification, other controllers receive the notification and do their own thing. In any case, for all your "how X can access Y" needs, the Application object usually instantiates everything and connects everything, so the application passes Y to X so that X can access Y. – Mike Nakis Dec 10 '15 at 21:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.