• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

One view/controller, pluggable models

 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Ranch Hand
Posts: 3061
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 580
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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").
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 3061
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 3061
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 580
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 3061
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Ranch Hand
Posts: 516
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 516
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 516
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 guess I've been abducted by space aliens. So unprofessional. They tried to probe me with this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic