调解员模式是否适用于这种情况？

Question

So for my current project, there are basically three main Java classes:

1. GUI
2. Instant Messaging
3. Computation

Essentially, there needs to be full communication, so we've decided to use the mediator approach rather than than allow the GUI to run the entire project.

Basically, the mediator is going to encapsulate the communication. The problem we've run into is how to allow the GUI components to update without building a ton of methods for the mediator to call anytime something completes.

Ex. Say the GUI wants to log in the user, it goes through the mediator to create a thread and log in, but then the mediator has to relay the success/failure back to GUI as well as update a status message.

The other issue is things that need to update the GUI but do not need the moderator. Is it practical to just allow the GUI to create an instance of that class and run it or should everything go through the mediator?

Our original design just had the GUI managing everything, but it really killed reusability. Is there a better design method to use in this case?

Answer 1

If you're finding Observer to bring too much overhead, Mediator may be the best way to go. I definitely think that you shouldn't have the GUI run the show. If you're going to use the Mediator pattern, the mediator itself should be in charge. Something you might consider is a variant of the Command pattern. If you were using Ruby, I might recommend passing function callbacks around as a means of avoiding having the mediator contact the GUI for every little thing. But since it's Java, some form of encapsulating an action in Command pattern style may help.

Answer 2

If you don't want the callback/notification to be triggerd by the mediator, you can inject the callback into the login function and have login call it when it finishes.

I don't know how you would go about injecting the callback in Java, though. In a language where functions are first class citizens, you could just pass the function, but you're in Java so I guess you will have to use the command pattern as kmorris suggested.

Answer 3

You might also try having the GUI give the mediator a callback object that handles retrieving return values or setting whatever values you need (a version of the Command pattern). There would then be one per call from the GUI to the mediator.

Another thought is to group the methods the mediator calls into semantically related chunks. In particular if the mediator has sections where it tends to call several GUI methods in a row:

   gui.a()
   gui.b()
   gui.c()

you can create a single method that handles the result of calling all three. The advantage of semantically grouped methods (ie setFileInformation over setFileMenu , setTab , etc.) is also then if you need to change the GUI, the contents of the methods might change, but the call the mediator makes may not.