Issue: There are several times when different objects need to be able to communicate with each other. This could be accomplished by using the observed and observer pattern, or by having an object using the mediator pattern, or both.
Discussion: Here are the items which need to communicate and with whom.
| Observer | Observed | Characteristic/Event |
| Team | League | Team Count |
| League | Team Size | |
| Team | Members/Bowlers | Member/Bowler Deleted |
| Lanes | League | Team Count |
| Contest Dates | League | Start Date |
| League | Contest Count | |
| Member | Team | Member Change |
| Treasury | Team | Member Change |
| League | Team Count | |
| League | Team Size | |
| League | Contest Count | |
| League | Contest Fee | |
| Member | Bowlers | Bowler Deleted |
In some of these cases, the observed object is a collection (Members), and in others it is a Record within the collection (League). This presents several challenges. In the case where the observed object is a Tic, I could make the Tic be observable/listenable and assign an observer/listener to it. The change message from the observable to the observer will need to contain the information about the change. This is well documented in the JavaBeans PropertyChange classes. One problem is that the observer cannot be registered until both the observed object and the observer object have been created.
Another possible method is to have a mediator collect all change messages from an object when it is "saved", then send those messages to all other collection objects, which will in turn send them to all record objects. Then only the interested objects would take any action, whether it be a collection, or a record. This eliminates the need to register observers and the timing issue with registering.
Creating the change message would be important, making sure that the nature of the change can be easily understood. An Enum sounds like a possibility. For example, if the change is from a collection, such as the deletion of a Member from a Team, then the deleted Member has to be part of the message. But, if the Member has already been deleted, there would be no reference available to the Member! If the change is to a Tic, then a reference to the Tic would provide the new value, assuming there is also the reference to the object that contained a value for that Tic.
When a league is first being set up, all of the information in the table above, must be provided to the observer objects so they can correctly instantiate themselves. The problem is that as the league object is saved, for the first time, the observer objects don’t yet exist. They will need to be created before any change message can be sent to them. I’m not sure how to do this.
Conclusion: The second method, of having the mediator send any change message to all collections, seems best because only the observer objects need code to process the change. The other objects can simply ignore the change message.