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.
1 ( model ). DataBase - this class performs low level read/write/delete operations on some type of database ( specifics not important ). I consider this to be the model layer.
2 ( controller ). I have a Service class. This class implements Observable. It also defines read/write/delete methods which a client will use to interface with the database. It delegates the actual work of these actions to the DataBase class.
3 ( view ). I then have a GUI SWING class. It implements Observer. This class uses an instance of Service to perform database operations and get notified of events. It adds the instance of Service to its Observables collection so that when events in that class take place, the GUI can update accordingly.
I'm wondering if a deign such as this can be considered MVC. This application is just for my own use to learn design patterns.
I agree with Matthew. The view has to be ignorant of the controller. Maybe what you'd need is it to provide methods for registering a Controller's listeners.
Based on the user request, the Controller calls methods in the View and Model to accomplish the requested action.
In practice, there is usually a significant relationship between a View and a Controller. The View represents how a human user will interact with the Model application. The Controller mediates communication between the View and the Model. All activities are started from the View, i.e. the human user. The View sends data to the Controller and receives data from the Controller.
The purpose of the pattern is to separate and eliminate code dependencies between the Model and one or more Views. Ideally, all functionality in the Model application should be able to be executed from a command-line. And from a code perspective, nothing in the Model is dependent upon anything in one or more Views or one or more Controllers.
Aside, the Model-View-Controller design pattern, and design patterns in general, are suited for large systems with many, many objects interacting with each other in many complex ways. The benefits of designing the application with known and well-thought design patterns are truly realized when the application is large.