Tyler Kenna wrote:Best way to remedy this: Observer and Observable. Observable has two methods called setChanged() and notifyObservers(). If your model is now observable, it doesn't care what views are watching it. It just calls notifyObservers(). Now in your driver class or your controller, you can call model.addObserver(view) which will make your view class (which has implemented Observer) "listen" to the Observable model. When it hears model call notfiyObservers(), it then runs its own update() method (required by Observer) and carries out whatever code you have placed in it. That way, you can create both classes without either one having to know about the other.
Thanks for the info, but I think what you explained is exactly what I'm doing. In the main driver class I create a model and view and then I add that view to the model as an "Observer", if you look at my model class you will see that there is an addKarateTermView() method which allows me to add an interface allowing me to make multiple views which all share the same refresh() method. It's like using Observer and Observable but I haven't really dealt with those classes specifically so I made my own methods. The model has an updateModel() method which would be equivalent to the setChanged() and when updateModel() is called in the model it calls an updateViews() method which would be equivalent to notifyObservers().
I took this model from here
but I have also seen it implemented in the Head First Design Patterns book in an example where a company has a weather meter spitting out data that it wants displayed, they go on to show you how to do this creating your own methods.. They discuss this pattern just before they introduce the Observer and Observable features stating that basically we didn't need to create those methods since java has the utility built in. Now, it does say in the book that their implementation is a bad one because their views are concrete and thus making the code too tightly coupled but I thought that's what using the interface would do to help. I just chose to do it this way to get a better understanding of how it works. This is a picture from a webpage
which also depicts the specific MVC model I chose to use. There is a description of what the numbers mean but this shows you the idea.
Basically, my model doesn't know about the views it just has an array of observers which get updated with the model's data. And my view is not aware of the model, it just knows that it will be getting some data through an inherited refresh() method so that it can update its fields. When my view performs an action, the controller sees it and notifies the model if necessary and possibly updates all of the views.
But, all that being said, I will try to work on implementing the Observer and Observable features since they would decouple my objects even further eliminating the need for the model to be aware of the specific interface(s).
What I am still trying to figure out though, is what data am I supposed to send my views in the refresh method? In the first link I provided from roseindia.net they just have a very simple model and view where the view only shows four stings of data and the refresh method sends the four strings. The Head First book showed an example that used three strings. I'm dealing with a quiz that could have 100+ questions and a variable number of choices, should I have the method break down each question and just send something like refresh(String question, String choices)? This way the view wouldn't have access to the actual Quiz object. I'm guessing that is the key of the view, not only should it not be aware of the model but it shouldn't be passed any objects otherwise then the object could be manipulated by the view. Is this the right mindset?