I’m working on an academic project which simulates a rather large queuing procedure in java. The core of the simulator rests within one package where there exist 8 classes, each one implementing a single concept. Every class in the project follows SRP. These classes encapsulate the behavior of the simulator and inter-connect every other class in the project.
The problem that has arisen is that most of these 8 classes are, as is logical i think, tightly coupled and each one has to have working knowledge of every other class in this package in order to be able to call methods from it when needed. The application needs only one instance of each class so it might be better to create static fields for each class in a new class and use that to make calls -instead of preserving a reference in each class for every other class in the package (which I’m certain that is incorrect)-, but is this considered a correct design solution? or is there a design pattern maybe that better suits my needs?
It sounds you have a kind of a complex state machine. You could abstract the method calls between the objects as asynchronous events. Instead of directly calling a method on the other objects, each object could send generic events to a ‘router’ object. The router object would forward the event to any number of objects who registered their listeners at the router. You can implement filters in the listeners or in the router algorithm to restrict who receives the events. State changes would be published as events too.
If you use a JMS server as the ‘router’, you could even distribute your objects on multiple hosts.
This approach provides a simple, reusable interface between your objects in the form of a common event schema/interface.