What is the right way to implement communication between java objects?

Question

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?

Answer 1

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.

Answer 2

Have you thought about using interfaces to decouple the classes? You have eight classes but it's possible that you will only need a few interfaces to enable communication/interoperability between and gain a good deal of flexibility.

Answer 3

The problem that I 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.

That is okay. The smallest unit of implementation (outside of individual classes) for Java components is the package. Classes within a package can be tightly coupled. Just make sure that the coupling does not leak outside (use package-protected classes for example).

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)

If every of these eight classes needs to have an instance of all other seven classes, maybe the way you split functionality across classes is not good. If every class has only a single area of responsiblity, why does this heavy cross-dependency arise?

Are these classes with state? Or just a collection of methods that might as well be static?

But again, as long as the public interface of this package looks okay, I would not worry too much. Does client code also need to know about the eight classes?