CSC/ECE 517 Fall 2007/wiki3 6 aa: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 95: Line 95:
* '''More Classes''' Can lead to lots more classes than expected.  Careful design and understanding is necessary to avoid both more classes as well as have lesser number of classes
* '''More Classes''' Can lead to lots more classes than expected.  Careful design and understanding is necessary to avoid both more classes as well as have lesser number of classes
* '''Design Trace''' It becomes hard to determine which functionality should be implemented where.  The base difficulty of coding is simple, but maintaining the design is sometimes confusing and tasking.
* '''Design Trace''' It becomes hard to determine which functionality should be implemented where.  The base difficulty of coding is simple, but maintaining the design is sometimes confusing and tasking.
== References ==
* http://java.sun.com/blueprints/patterns/MVC-detailed.html
* A better explanation: http://ootips.org/mvc-pattern.html
*
== Further Reading ==

Revision as of 00:54, 20 November 2007

Topic

Controller Pattern

Take the Controller pattern (which we did not cover in class) and catalog the information on it available on the Web. Find good descriptions and good, concise, understandable examples. Tell which you consider the best to present to a class.

What Is

Controller Pattern

This is usually also called as Model-View-Controller Pattern. The essence behind this is that when the business logic or data access components are large, a Controller class is introduced between user interface (View) and the core logic (Model).

A very good example for this is the Java Swing Architecture. In Swing, all GUI is defined via objects and classes derived from the JComponent object. The business logic is defined in ActionListeners, Event Descriptors.

To put things simply,

An easy way to understand MVC: the model is the data, the view is the window on the screen, and the controller is the glue between the two. -- ConnellyBarnes

SmallTalk

However intuitive and simple idea it is, it has an origin in this work and its inventors (TrygveReenskaug and others). Lets discuss how it actually works. This is not a chat application as is usually the perception, but is actually a language that is inspired by the desire to make human computer interaction simpler and smoother. The language has the concepts of object oriented Programming and each object has only following properties,

  1. Hold state (references to other objects).
  2. Receive a message from itself or another object.
  3. In the course of processing a message, send messages to itself or another object.

The state an object holds is always private to that object. Other objects can query or change that state only by sending requests (messages) to the object to do so. Any message can be sent to any object: when a message is received, the receiver determines whether that message is appropriate.

The working clearly indicates the semblances of the MVC pattern. [[1]]

An Example

Http Request

 Browser           View              Controller      Model
   .                 .                 .               .
   . HTTP Request    .                 .               .
   +---------------------------------->+               .
   |                 .                 | update model  .
   |                 .                 +-------------->+
   |                 .                 |               |
   |                 .                 | return status |
   |                 .                 +<--------------+
   |                 .     select view |               .
   |                 +<----------------+               .
   |                 |                 .               .
   |                 | query state     .               .
   |                 +-------------------------------->+
   |                 |                 .               |
   |                 |                 .  return state |
   |                 +<--------------------------------+
   |   HTTP Response |                 .               .
   +<----------------+                 .               .
   .                 .                 .               .

[[2]]

Working

The working of a MVC model is simple, and is usually done via multiple steps. Its an extremely verbose model in the sense that there are loot more classes than need be, for a simple application.

The entry point of a request is Controller, and based on that it updates model, and then selects view. The logic for both are given in the controller. Once the view is selected, the view directly queries the model for necessary data, the response for the request is given to the user.

There are a few points here that must be understood.

  • The request arrives at controller, and does not go through the view.
  • Controller(s) merely select the view.
  • Controller only updates model.
  • Interactions between the View and model are not monitored by the controller.
  • View only queries the model.
  • Response is displayed or returned to the user view the view.

This example

It has a few important advantages

  • Views can be changed without touching the actual model implementation.
  • Requests are seperated from the model implementation. Controller acts as the shield between data and the logic.
  • Lastly, Requests are independent of the views. and response views can be changed as per logic.

Advantages

The MVC model, has a lot of advantages. All of them are due to the simplicity of design.

  • The greatest advantage is the clarity of design. When designing the application, this trait makes the entire program easier to implement and maintain.
  • Efficient modularity of the design allows any of the components to be swapped in and out as the user or programmer desires - even the model!
  • Multiple views Consider a PC game. It would be extremely easy to allow the user to customize the in-game player. Game environment, music, everything can be changed accordingly without touching the complicated game logic.
  • Scalability Due to its simplicity and clarity of design, its very scalable and can be extended with multiple functionalities in the end.
  • User Interface The user interface is also extendable, an example for that is macros and custom keys. they can be implemented as a series of standard commands issued to controller.

Disadvantages

Its disadvantage arises only from the fact that its extremely verbose.

  • More Classes Can lead to lots more classes than expected. Careful design and understanding is necessary to avoid both more classes as well as have lesser number of classes
  • Design Trace It becomes hard to determine which functionality should be implemented where. The base difficulty of coding is simple, but maintaining the design is sometimes confusing and tasking.

References

Further Reading