Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"
JavaRanch.com/granny.jsp
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Hook methods again! Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Hook methods again!" Watch "Hook methods again!" New topic
Author

Hook methods again!

Sam O'Neill
Ranch Hand

Joined: Nov 25, 2002
Posts: 57
Hi Everyone
I have been reading all about the use of 'hook' methods in the GUI to enable the greater encapsulation of the View class from the Contoller class and can certainly see the benfit of this except for one part that has me scratching my head.
If we manage to get to a situation where there is an overall application control class, lets call it mainClass, that instantiates the View class followed by the Controller and passes a reference to the View class to the Controller class so that it can call the hook methods, then if the View now knows nothing about the Model and Controller how does it populate its JTable, Origin and destination components, for example, to begin with? It can't call contoller.getTableData() or controller.getDestinations() as it doesn't know about controller.
With the hook method way of doing things the Controller class methods are only called in response to input events - when the View class displays its components there are no callbacks taking place due to events so how does the View class call upon the Contoller to supply it with the information it needs.
I am definitely missing some magic here - any help would be greatly appreciated
The View class has hook methods but these methods only get called
Many thanks in advance
Sam
John Smith
Ranch Hand

Joined: Oct 08, 2001
Posts: 2937

then if the View now knows nothing about the Model and Controller how does it populate its JTable, Origin and destination components, for example, to begin with?

A standard solution to this is an Observer-Observable pattern. Your model acts as an observable, and your views are registered as observers. When the model executes a business method and comes up with the results, it fires a broadcast to all listeners. That broadcast may contain the results. The views can now determine the type of broadcast, retreive the results, and display them. For example:

In this solution, the views actually know about the model, but for a single purpose, -- to register themselves as model listeners.
Eugene.
[ January 06, 2003: Message edited by: Eugene Kononov ]
Aruna Raghavan
Ranch Hand

Joined: May 14, 2002
Posts: 194
Eugene,
This Observed-Observable pattern takes Controller out of picture,doesn't it?
Aruna.


Aruna A. Raghavan<br />SCJP, SCJD, SCWCD
John Smith
Ranch Hand

Joined: Oct 08, 2001
Posts: 2937

This Observed-Observable pattern takes Controller out of picture,doesn't it?

No, it doesn't take Controller out of the picture. Think of MVC as a pattern that is built using another pattern, Observer-Observable.
Eugene.
Aruna Raghavan
Ranch Hand

Joined: May 14, 2002
Posts: 194
Eugene,
So,Controller only gets involved to send a search/booking request to the Model but the View receives events directly thr' the broadcast from the Model? In other words, Controller does not subscribe to these DataAvailable type of events?
Aruna.
John Smith
Ranch Hand

Joined: Oct 08, 2001
Posts: 2937

So,Controller only gets involved to send a search/booking request to the Model but the View receives events directly thr' the broadcast from the Model? In other words, Controller does not subscribe to these DataAvailable type of events?

Right, the controller job is to select views, to listen to user actions, and invoke business methods on the model.
Eugene.
Aruna Raghavan
Ranch Hand

Joined: May 14, 2002
Posts: 194
Thanks, Eugene. That makes sense.
Aruna Raghavan
Ranch Hand

Joined: May 14, 2002
Posts: 194
Eugene,
What's wrong with Controller just pushing a button on the View to tell it that data is available. Is it wrong because the View and Controller are tightly coupled? I mean Controller has to know about the View anyway...
I guess another argument would be that if we wanted to enhance this app to provide automatic updates to all compnents of View that need the data update, a more generic mechanism like the Observed-Observable pattern makes sense, right?
Thanks,
Aruna.
John Smith
Ranch Hand

Joined: Oct 08, 2001
Posts: 2937

What's wrong with Controller just pushing a button on the View to tell it that data is available. Is it wrong because the View and Controller are tightly coupled? I mean Controller has to know about the View anyway...

I am not sure what you mean by "Controller just pushing a button on the View".
Regarding the other question, although the controller knows about the views, it's not much coupling, because all the controller does is to invoke the show() and hide() methods of the views. Therefore, all the views can keep all their stuff private, and they can change without affecting the controller (or the model).
Eugene.
Aruna Raghavan
Ranch Hand

Joined: May 14, 2002
Posts: 194
Eugene,
By "pushing a button", I meant "calling a method". (C++ OO slang).
Aruna.
Jai Karuppuswamy
Greenhorn

Joined: Jan 22, 2002
Posts: 11
Originally posted by Eugene Kononovalthough the controller knows about the views, it's not much coupling, because all the controller does is to invoke the show() and hide() methods of the views

I am having a tough time deciding on how loose this coupling (between view and controller) should be.
First, I have my controller implement action listeners for the different buttons in the view. But with this, my controller still has to call methods on the view to get information from text fields, like.

I am now thinking of refactoring this design, using the same observer pattern that I have used for my model-->view notification. I would package all the information entered in the UI into a FlightEvent and then notify the view's listeners of this event. The controller would be registered as the listener for FlightEvent's from view.
Would this be stretching it a bit too far. Shout away.
Thanks,
Jai.


If everything is under control, you're going too slow.<br /> Mario Andretti
Sam O'Neill
Ranch Hand

Joined: Nov 25, 2002
Posts: 57
Thanks for the replies guys

Sorry I've come in on the tail end of this as I'm in a different time zone but as I understand it Eugene we create the View in such a way that it is as encapsulated as possible. We therefore want to create all its components as private and the View's responsibility is to take care of displaying its components and providing all the possible hook methods needed for assigning event handlers, obtaining selected values and calling setVisible on the View itself. The methods will then be called by the Contoller as required.
In order for the View to obtain information from the Model so that it knows how to initialise and update the values contained in its components it should subscribe to events issued by the Model thus it will in fact need a reference to the Model if not the Controller.
So I guess my question is now that if we are going to do all this so that we can neatly divide up responsibilities between each of the Model, View and Contoller should we then expect the View to conform to a particular interface? I ask this because it is not strictly true to say that we can then just swap out the View due to its tight encapsulation as the Controller would be depending on it to provide certain methods, a different View would also have to provide these methods. I have never seen anyone ever mention an interface for a View so i was wondering what people think about it?

Many thanks Sam
John Smith
Ranch Hand

Joined: Oct 08, 2001
Posts: 2937

In order for the View to obtain information from the Model so that it knows how to initialise and update the values contained in its components it should subscribe to events issued by the Model thus it will in fact need a reference to the Model if not the Controller.

Well, here comes the magic of loose coupling, -- although the View needs the information from the Model, the View doesn't need to call any methods on the model to obtain the model state, -- this (weakly typed) information can be "pushed" from the model to the views. If implemented as such, the View then needs a reference to Model for one single purpose: to register itself as a model observer. Subsequently, the views and the model can be changed without affecting each other.
There is also an alternative
"pull" approach.
Eugene.
[ January 07, 2003: Message edited by: Eugene Kononov ]
Fred Barnes
Ranch Hand

Joined: Jun 11, 2002
Posts: 62
Hi Eugene,
Cant the Controller who has a reference to the View and Model register the View as a observer to the Model?
Regards
Fred
Sam O'Neill
Ranch Hand

Joined: Nov 25, 2002
Posts: 57
Thanks for that Eugene
Sam
Aruna Raghavan
Ranch Hand

Joined: May 14, 2002
Posts: 194
Fred,
Look at the recent "Is this MVC" thread. The answer to your question is- yes, it can be done that way.
Aruna.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Hook methods again!