This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Hi all, 1.If I wanna follow standard MVC pattern,does it mean that I'll have to create my own controller class, and add listeners on the components on my own? 2.how do I acquire the view reference in my controller class? My way is to put all the initialization and drawing in the constructor in view class,and just create a new view class in the controller. something like the following
Is it OK? or is it an ugly way to acquire the view reference? 3.how do I operate the model? in order to follow the "program with the interface" rule, I chose to operate the model via the setValueAt() method in the TableModel interface, then I'll have to set values cell by cell in the controller and it seems not so elegant. 4.About the "hook method". Do I have to make one different hook method for every component which needs to have a listener?like assignActionToButtonA(); assignActionToButtonB(). looks cumbersome... final question, seems controller will have knowledge about both V & M, right? well,these questions maybe very silly, as I'm really new to this thanks for your help! --eliot [ November 13, 2003: Message edited by: Eliot Skywalker ]
No matter who you listen to, not matter who the expert is or claims to be, there are several ways to implement the MVC pattern. The key is to make the three pieces (model, view, and controller) "plugable" and uncoupled. Meaning you could easily replace any three with another class. How do you do this? The best way is to keep you lines of communication small and if possible uni-directional. Meaning the view may call the controller but the controller does not make calls to the view. The controller instead makes calls to model, receives information back from the model and returns the result back to the view. In this scenario the view has no idea whow the model is, the controller has no idea what the view is. The only relationship you have is that the view knows the controller and the controller knows the model. However, you could design numerous other ways, just try to keep them uncoupled and always ask yourself if the relationship between the 3 components is to tight. One more important thing that most people agree one: 1. Your view should simply be just that, a view, no inner class listeners or business logic and no exception handling. 2. The model is simply just the representation of the data. No exception handling. You may need a listener. 3. The controller is often you listener and performs the exception handling. This is up for debate. Some people create a whole other class for this. But one thing a controller does is acts as a proxy to the outside would. In this case being the server whether it be remote or not. Resources: (notice how they are both very different and both come from experts, one being sun itself) 1. http://www.churchillobjects.com/c/14058c.html 2. http://java.sun.com/blueprints/guidelines/designing_enterprise_applications/introduction/summary/index.html