Thanks John, I'm thinking about your suggestions now. I agree with your point about tight coupling. An inner class would definitely work in this scenario, but isn't that more tightly coupled than my current solution?
John de Michele wrote:
This works for me to some extent, but the communication between the GUI and the Configuration is two-way. To me, your pseduocode implies that the GUI will call Configuration methods, but not necessarily vice versa.
I'll show a bit more source code, stripped-down of course:
(I've named variables such that a graphical solution is implied, but please note that this design allows the "GUI" to be substituted with anything that provides the right accessor methods, e.g. "boolean doOperationA()". A text GUI could quickly be made, for instance.)
So you see, John, in my current mindset, it's impossible to make the Configuration independent of the GUI because the GUI is the Configuration's data/state source. I did say "in my current mindset": you're right to indicate that if my division of labour/assignment of responsibilities is off, then I'll have to rethink things considerably.
When I tried to make Configuration more independent, I ended-up putting more domain logic in the GUI:
So now the Configuration no longer needs to access the GUI for this information. This still leaves the problem of having the Configuration report back to the GUI when certain events occur (e.g. "Operation A is complete."), but I could use an observer
pattern (i.e. the Configuration will announce to its listeners). Overall though, it doesn't feel any better.
Gerardo, thanks for replying. That's similar to what I'm currently doing, but I worry about passing the Configuration constructor a partially initialized GUI object. I might be worrying unnecessarily, as long as I don't do work in the constructor.
Ah, my carpool is waiting. See you tomorrow.