wood burning stoves 2.0*
The moose likes OO, Patterns, UML and Refactoring and the fly likes One view/controller, pluggable models Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "One view/controller, pluggable models" Watch "One view/controller, pluggable models" New topic
Author

One view/controller, pluggable models

Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Ilja (or anyone) I started a new thread to take off on something we both said: The model should never know about the view.

Can you imagine a design where a common view has pluggable models? Perhaps I market a neat dashboard view/controller that can provide real time monitoring of any app model. All your app model has to do is implement a few interfaces so I can watch it. Would that be a model that has to know about the view/controller?

Rats, in this example I might make the application model and the dashboard model peers that can freely converse over some protocol, and the dashboard view stays nicely separated from the dashboard model. Was that just a poor example or are there no good examples that would force backwards dependencies here?
[ May 04, 2005: Message edited by: Stan James ]

A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Layne Lund
Ranch Hand

Joined: Dec 06, 2001
Posts: 3061
I'm not sure what lead up to this comment, but I find it curious that the model shouldn't know about the view. In a recent program Connect Four game I wrote for a class project, I tried my hand at implementing it with an MVC. The model had a reference to the view so that when changes were made to the model it could then notify the view that it needed to update the game board for the player. I guess an alternative would be to have the controller send the changes to the model and then tell the view to update without relying on the model to update the view. Why would the later be preferred over the former?

Layne


Java API Documentation
The Java Tutorial
James Carman
Ranch Hand

Joined: Feb 20, 2001
Posts: 580
The model does need to have a reference to the view in order to notify it, but it doesn't need to "know about" the view. The view should register itself (or some other object which knows how to update the view) as a listener on the model to receive events when the model changes. The model only knows about the listener type (an interface), not the specific type of the view (or the "other object").


James Carman, President<br />Carman Consulting, Inc.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Stan James:
Rats, in this example I might make the application model and the dashboard model peers that can freely converse over some protocol, and the dashboard view stays nicely separated from the dashboard model. Was that just a poor example or are there no good examples that would force backwards dependencies here?


I'd say it's the latter.

Isn't that exactly how Swing works? A JTable works on a TableModel, which is an interface. The JTable doesn't depend on the actual business model, and the business model doesn't depend on the fact that it gets viewed view a JTable.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Yeah, I think it's the latter, too ... it just shouldn't happen.

To back up a ways, one motivation for keeping the model totally ignorant of the view is to allow multiple views. My project has an app server that is called by a Swing client and by a web client. That would be harder if the model depended on Swing widgets or servlets.

Managing dependencies, turning them around when you have to, is a fun part of design. One man's opinion.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Stan James:

Managing dependencies, turning them around when you have to, is a fun part of design. One man's opinion.


I wholeheartedly agree! It's a very rewarding moment when you suddenly can reuse some code in a myriad of ways, just because you flipped some dependency...
Layne Lund
Ranch Hand

Joined: Dec 06, 2001
Posts: 3061
Originally posted by James Carman:
The model does need to have a reference to the view in order to notify it, but it doesn't need to "know about" the view. The view should register itself (or some other object which knows how to update the view) as a listener on the model to receive events when the model changes. The model only knows about the listener type (an interface), not the specific type of the view (or the "other object").


That's basically what I did. I have an ConnectFourView interface that the model and controller use for these kinds of notifications. I'm glad to see that I might be on the right track here.

Layne
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
The next step is to wonder who OWNS that interface. If you bundle it up in the model PACKAGE, I'm all smiles.
Layne Lund
Ranch Hand

Joined: Dec 06, 2001
Posts: 3061
Originally posted by Stan James:
The next step is to wonder who OWNS that interface. If you bundle it up in the model PACKAGE, I'm all smiles.


I didn't get too overly complicated with my package names. Since the main focus of the project was the AI for the game, I split it into connectfour.gui and connectfour.ai packages. All of the MVC classes resided in the GUI package. Although this may not be an ideal solution, it seemed to work other than the fact that the AI agent classes used the model as well. It may have been better to separate the model and related classes (such as the view interface) into yet another package. That definitely gives me something to think about.

Layne
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Robert Martin has written a lot on packages and package dependencies. This gets to be important if you use packages as units of compilation and deployment. If you sold the model as a shrinkwrap product or provided it to several different project teams in your company with different release schedules you'd want to be sure you can deploy new views without recompiling and redeploying the model. If the entire system is in your workspace you might care a lot less.
James Carman
Ranch Hand

Joined: Feb 20, 2001
Posts: 580
Originally posted by Layne Lund:


That's basically what I did. I have an ConnectFourView interface that the model and controller use for these kinds of notifications. I'm glad to see that I might be on the right track here.

Layne


I wouldn't necessarily call it ConnectFourView. Because, it doesn't have to be a view at all that's listening for changes to the model. If you have to call it something, call it ConnectFourModelListener. It doesn't really make a difference in code, but a model shouldn't have to know about a "view" class or interface. It's supposed to be the other way around.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Stan James:
If the entire system is in your workspace you might care a lot less.


That also depends on the size of the system. When systems get bigger, it becomes more important to manage package dependencies, so that the system remains flexible and maintainable, in my experience.
Layne Lund
Ranch Hand

Joined: Dec 06, 2001
Posts: 3061
Originally posted by James Carman:


I wouldn't necessarily call it ConnectFourView. Because, it doesn't have to be a view at all that's listening for changes to the model. If you have to call it something, call it ConnectFourModelListener. It doesn't really make a difference in code, but a model shouldn't have to know about a "view" class or interface. It's supposed to be the other way around.


I like that idea. For now this project is "finished" since the homework deadline has long passed. However, it was interesting enough that I may revive it and clean it up a little. I keep this suggestion in mind if that ever happens

Layne
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
That also depends on the size of the system. When systems get bigger, it becomes more important to manage package dependencies, so that the system remains flexible and maintainable, in my experience.


Absolutely. I just meant that some of Robert Martin's arguments about building and deploying packages don't resonate with projects like mine where we build and deploy everything every time. Some of these things matter "less" to us than someone who sold a package commercially, but not zero fer sure. I still like to pretend that the core packages are "shrink wrapped" and "closed" to change in the normal release cycle. It's a fantasy that hasn't caught on with the troops very well.
Alex Belisle Turcot
Ranch Hand

Joined: Apr 26, 2005
Posts: 516
Hi,

I know there were a lot of post about MVC and I read most of them.

I would still like to have your opinions on my interpretation of this pattern.

I'm trying to create some classes that I could re-use every/most everytime I implement the MVC pattern. (I know it might be impossible, but I will try).

My code for it is at home, I will post it later tonight..

Some statement:
The Controller implements EventListener, ActionListener... Neededlistener

The View will accept references to EventListener and will add them to the widgets: Buttons, frame...

Hence, the view doesn't have any references to the Controller.

The Controller will handle the event thrown by the GUI.

The Model holds references to Observer(Views) without knowledge of them being Views : the Observer are notified.

The Model doest have any references of the Controller.

The view doesn't have any references to the Model (only for a short time, just to add itself to the Model Observer list).

The View doesn't keep any references to the Controller.

The Controller holds a reference to the Model and will modify it when needed.

The Controller does not keep any references to the View.

Later on, the GUI will trigger an event, the controller will know about and modify the Model. The model will notify its Observer(View) and the GUI will be updated.

How does that sound ?

Thanks,
Alex
[ May 11, 2005: Message edited by: Alex Turcot ]
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Looks like a lot of good thought there. I took the liberty of making pictures ... see if they match what you said or if I demonstrate a total lack of listening skills ...

I think the "as described" ones match what you suggested. The alternative initialization just shows the assembler (which you called main) doing a little more so the View never has contact with the Model at all.

Your event scenario implies the model sends any changed or interesting data along with the event to the View listener. That certainly works, and is actually my preference. I think a more common alternative just tells the View that something changed and the View has to call back to get the changed data. My alternative init never gives the model to the view so it won't support the alternative event. Self consistency ... don't believe the hype.
Alex Belisle Turcot
Ranch Hand

Joined: Apr 26, 2005
Posts: 516
Hi,

Here is what I meant exactly :



What I mostly want to point out is the fact that the Controller doesn't know the view. The model doesnt know the Controller and the view. The view doesnt know the controller and the Model.

Only 1 class knows something : the Controller knows the Model.

The "View"(GUI) talks to the controller via Listener.
The Model talks to the views via Observer.

Regards,
Alex
[ May 11, 2005: Message edited by: Alex Turcot ]
Alex Belisle Turcot
Ranch Hand

Joined: Apr 26, 2005
Posts: 516
Hi,

This is the code for my mvc.

main:


View:


Controller:


Model:


In the controller, registerView() and addModel() do the same as register(). I added both to be able to add several views or models...

The part i'm lacking is the order of creation of either the view (or model?)
For instance, if the model is added after the views, the Views won't know about this Model... but I'm not sure if that's a problem...

The method addListener() in the view accept EventListener as args which is wider than should be.
The implementing view will then overload this function with more precise listener like "ActionListener".
Than, if a Controller tries to listen to the view with an un-overloaded method (MouseListener for instance), the Exception UnsupportedListenerException will be thrown.

Your comments are welcome,
Alex
[ May 12, 2005: Message edited by: Alex Turcot ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: One view/controller, pluggable models