MVC and OO Design?

ruby-talk
1

The Model View Controller Architecture has always had me a bit
puzzled.
As I understand it, when the Model gets updated, the Model notifies
the Views that the Model has changed. The Views then query the Model
and draw themselves.

Now since the Model has the data, the first obvious place to put the
drawing code would be with the model and passing the View as a
parameter. However, if there are multiple ways the model might be
drawn, say as a graph or as a chart, then maybe you don’t want the
drawing code in the Model. After all, every time you want a new way
to view the Model, you have to open up the Model code to add the
class. With this design the class is never closed.

However, if you put the drawing code in the View, how does the View
query for the data? It seems that virtually all of the Model’s state
information needs to be made readable. After all, some future View
design may need some piece of state that was not thought of earlier in
the design. Perhaps some of the state data can be determined to be
private, and only the essential properties of the Model need public
read accessors. However, always making the Model’s properties
readable seems ugly to me. Fortunatley, Ruby makes this much easier
than other languages using attr_reader. In Java, it just seems
impractical.

This problem comes up more generally in OO programming also. In
general, a class will never have every method that a programmer can
think of. For example, a String class will probably not have an
encryption function. Thus string must expose its internal state in a
read only fashion, to allow a future encryption function to be
written. In the case of String, it is easy to expose the internal
state. However, for more complex objects, it generally is not.

Ruby does help this problem on two fronts. First, you can just use
attr_reader to make all state variables readable.
Second, classes in Ruby are never Closed. I could actually add an
encryption function to the String class. I don’t know if this is
wise. The encryption function could leave the string class in a bad
state. It is nice to know that a class is Closed and is correct.

I often feel the problem is easier to think about when objects are not
involved.
Show(Model, View). The Show function needs data from the model and
viewport information from the view in order to draw. If these are
just C Structs then there is no need to worry about accessors.
However, this leaves no encapsulation of the Model’s state data, which
is bad.

I guess my real questions are the following:

  1. Under the MVC scenario, does it make sense to expose all of the
    model’s data using attr_reader. What if the code was written in Java,
    where getter functions would be required for all data? Imagine a very
    complicated nested data structure that would require hundreds or
    thousands of lines to make readable.
  2. Would it be better to add the draw functions to the model by
    opening up the model later. Perhaps a view module could be created.
    This module would contain the code that opens the Model and adds the
    draw function or functions.
    What if you’re using Ruby and can’t open the class later, but you have
    to edit the only source for the class. In my case the source is
    available, but conceivably, in general, it might not be.

Any thoughts on this subject or good links would be greatly
appreciated.

2

The Model View Controller Architecture has always had me a
bit puzzled. […]

> [... putting drawing logic in the model, not a good idea
> because...] every time you want a new way to view the Model,
> you have to open up the Model code to add the class.  With
> this design the class is never closed.

Exactly, the purpose of splitting out the Model and View is to
separate the business logic (Model) from the display logic (View).

> However, if you put the drawing code in the View, how does
> the View query for the data?

Generally Model classes are written with Views in mind. The Models
don’t know the details of the logic within the Views, but it is the
responsibility of the Model to give the View enough information to do
its job. Providing public accessors is one way (and probably the
simpliest), but there are others.

Ignoring the Controller for now, the Model/View pair is essentially
the Observer pattern. There are two basic approaches to observable.

The first is the “pull” model. So named because whenever the Model
changes, it sends a simple notification message to the View. The View
then pulls the needed data from the object by querying it. This works
great for simple models with a handfull of attributes. But what if
the model contains dozens of separate fields. The view would have to
run through each of the individual fields to find the one that
changed.

Another way is the “push” model. Whenever the model changes, it sends
only the changed data to the observer. The data is somehow “tagged”
with identification so that the View knows what kind of data is being
sent. An interesting variation is to “tag” the data with a command
object (the View just invokes the command object). I’ve got a writeup
on the Observer Pattern and MVC at…

http://w3.one.net/~jweirich/development/talks/patterns/observer.html

Its in Java though … no Ruby version (yet!).

> It seems that virtually all of the Model's state information
> needs to be made readable.

Not all … just what the View needs. Generally the Model is written
with knowledge at a View will be using it and the Model designer
arranges that the needed data is available.

> This problem comes up more generally in OO programming also.
> In general, a class will never have every method that a
> programmer can think of.

Its impossible to completely predict how an object will be used. I’ve
learned over the years to provide what’s needed today, but keep the
code flexible enough so that new stuff can be added with little
effort. To me, it is more important to be flexible than complete.

> 1) Under the MVC scenario, does it make sense to expose all of the
> model's data using attr_reader.  [...]

Make available what you need today. If you need more tomorrow, just
add it.

> [...] Imagine a very complicated nested data structure that would
> require hundreds or thousands of lines to make readable.

I would move to a push model in this case. Still, hundreds (let alone
thousands) of accessors seems excessive. It may be time to refactor :slight_smile:

> 2) Would it be better to add the draw functions to the model by
> opening up the model later.  Perhaps a view module could be created. 
> This module would contain the code that opens the Model and adds the
> draw function or functions.

No, the draw logic does not go into the Model.

> Any thoughts on this subject or good links would be greatly
> appreciated.

Take a look at the observer pattern library in the Ruby distribution.

I hope this helps.

···

–
– Jim Weirich jweirich@one.net http://w3.one.net/~jweirich

“Beware of bugs in the above code; I have only proved it correct,
not tried it.” – Donald Knuth (in a memo to Peter van Emde Boas)

3

The Model View Controller Architecture has always had me a bit
puzzled.
As I understand it, when the Model gets updated, the Model notifies
the Views that the Model has changed. The Views then query the Model
and draw themselves.

I understand the MVC architecture completely differently. The nature
of the model is that it never initiates behavior and that it is
interface agnostic.

Now since the Model has the data, the first obvious place to put the
drawing code would be with the model and passing the View as a
parameter. However, if there are multiple ways the model might be
drawn, say as a graph or as a chart, then maybe you don’t want the
drawing code in the Model. After all, every time you want a new way
to view the Model, you have to open up the Model code to add the
class. With this design the class is never closed.

Again the model doesn’t have any knowledge of how it it being queried.
It should be equally accessible from a GUI, a CLI or an automation
language.

However, if you put the drawing code in the View, how does the View
query for the data?

The controller queries for data.

It seems that virtually all of the Model’s state
information needs to be made readable.

Yes, with the caveat that the controller doesn’t really know whether
the model is reporting or calculating. But don’t store information
about the state of the user interface in the model. Use controller
hierarchies for that.

After all, some future View
design may need some piece of state that was not thought of earlier in
the design.

So change the controller.

Perhaps some of the state data can be determined to be
private, and only the essential properties of the Model need public
read accessors. However, always making the Model’s properties
readable seems ugly to me. Fortunatley, Ruby makes this much easier
than other languages using attr_reader. In Java, it just seems
impractical.

I think this notion comes for you efforts to put too much in the model.

This problem comes up more generally in OO programming also. In
general, a class will never have every method that a programmer can
think of. For example, a String class will probably not have an
encryption function. Thus string must expose its internal state in a
read only fashion, to allow a future encryption function to be
written. In the case of String, it is easy to expose the internal
state. However, for more complex objects, it generally is not.

Ruby does help this problem on two fronts. First, you can just use
attr_reader to make all state variables readable.
Second, classes in Ruby are never Closed. I could actually add an
encryption function to the String class. I don’t know if this is
wise. The encryption function could leave the string class in a bad
state. It is nice to know that a class is Closed and is correct.

I often feel the problem is easier to think about when objects are not
involved.
Show(Model, View). The Show function needs data from the model and
viewport information from the view in order to draw. If these are
just C Structs then there is no need to worry about accessors.
However, this leaves no encapsulation of the Model’s state data, which
is bad.

I guess my real questions are the following:

  1. Under the MVC scenario, does it make sense to expose all of the
    model’s data using attr_reader. What if the code was written in Java,
    where getter functions would be required for all data? Imagine a very
    complicated nested data structure that would require hundreds or
    thousands of lines to make readable.
  2. Would it be better to add the draw functions to the model by
    opening up the model later. Perhaps a view module could be created.
    This module would contain the code that opens the Model and adds the
    draw function or functions.
    What if you’re using Ruby and can’t open the class later, but you have
    to edit the only source for the class. In my case the source is
    available, but conceivably, in general, it might not be.

Any thoughts on this subject or good links would be greatly
appreciated.

Just a general thought that you don’t seem to have grasped the function
of the controller. Think of the model as a passive thing that only
responds to messages. Think of the view as a passive thing that
responds to user input. The model has the business logic but the
controller has the program logic.

···

On Friday, September 13, 2002, at 05:44 PM, MetalOne wrote:

The higher we soar the smaller we appear to those who cannot fly.
-Friedrich Wilhelm Nietzsche, philosopher (1844-1900)

4

Jim and Chris have just offered some excellent advice. I would only add an
emphasis on not trying too hard up front trying to make correct choices.
Refactoring is not something to avoid, like an admission of guilt. It is
probably your most powerful OOP technique. For me it is the most fun part of
OOP programming. I am just finishing an MVC project. In the first
iteration, there was a lot of leakage between M, V and C. I knew it was
happening but trapping my ideas before they slipped away was more important
than “proper structure”. Now, in the refactoring stage, I concentrate on
disentangling the speghetti without losing functionality. The old adage is
correct: first get it working, then get it working right, then make it fast.
(And then make it pretty).

5

i have good news for you my friend. all though the code is not yet
realeased, the GUtopIa project has successfully solved these problems.
you do not have to touch you model one single iota, and yet with
GUtopIa’s Controller module you can access your model on two different
levels, as you see fit: either at the level of what the model exposes,
through public methods including accessor methods, or you can access the
model on a level that exposes it in its entirety, via any instance or
class variable. again, you can do this without touching the model code
at all. it is an “Automagiacal Observer”.

if you’re interested i can make the code available. i have been thinking
about releaseing this section of the code soon anyway as a seperate
offshoot project, becasue i realized it actually enables Declaritive
Programming (like Prolog) in Ruby. cool, ey?

···

On Fri, 2002-09-13 at 18:44, MetalOne wrote:>

I guess my real questions are the following:

  1. Under the MVC scenario, does it make sense to expose all of the
    model’s data using attr_reader. What if the code was written in Java,
    where getter functions would be required for all data? Imagine a very
    complicated nested data structure that would require hundreds or
    thousands of lines to make readable.
  2. Would it be better to add the draw functions to the model by
    opening up the model later. Perhaps a view module could be created.
    This module would contain the code that opens the Model and adds the
    draw function or functions.
    What if you’re using Ruby and can’t open the class later, but you have
    to edit the only source for the class. In my case the source is
    available, but conceivably, in general, it might not be.

Any thoughts on this subject or good links would be greatly
appreciated.

–
tom sawyer, aka transami
transami@transami.net

6

Thanks to all for your help.

I was really thinking very abstractly about a problem in my head that
MVC kind of demonstrated. I was in search of deep answers in regards
to when to include a function in a class and when not too. The common
wisdom states that when a function needs access to the classes data,
it should be included with the class. MVC strays from this notion
because the View needs access to the Models data and yet the View
functions are not placed in the class. Abstractly, any function could
be thought of as a view function, even if it does not draw a
representation of the object. This could lead one to conclude that if
a function does not change an object’s state, then it should always
reside outside the object and query the object for data, just like a
View object. Fat classes generally are not considered good design, so
I was trying to envision what it would be like to have very thin
classes, containing only functions that modify state. Writing all the
accessors seemed awkward though. I suppose as always there are no
hard fast rules and comprises are required.

The responses above brought me back to a more concrete reality. MVC is
there to separate out user interface code. It is also true, that I
did not understand the roll of the controller. Thinking of a passive
Model and a passive View has also helped me with my current problem.

Perhaps it is wise to pull functions out of a class along functional
lines that require specialized developer skills such as GUI, Database
Access, Encryption, etc. Or maybe it only makes sense for GUI,
because, of the need to easily change the GUI.

7

Chris Gehlker canyonrat@mac.com writes:

The Model View Controller Architecture has always had me a bit
puzzled.
As I understand it, when the Model gets updated, the Model notifies
the Views that the Model has changed. The Views then query the Model
and draw themselves.

I understand the MVC architecture completely differently. The nature
of the model is that it never initiates behavior and that it is
interface agnostic.
This is correct the Modell notifies the Controller or the other way
round the Controller queries the modell for needed input forwards it
to the Model get back the values from the Model and than updates the
View. This is the strict MVC model. I could imagine that there could
be some direct contact between Modell and View but hopefully just in
the way I’ve been updated. Look after it please.

Regards
Friedrich

···

On Friday, September 13, 2002, at 05:44 PM, MetalOne wrote:

8

I was really thinking very abstractly about a problem in my head that
MVC kind of demonstrated. I was in search of deep answers in regards
to when to include a function in a class and when not too. The common
wisdom states that when a function needs access to the classes data,
it should be included with the class. MVC strays from this notion
because the View needs access to the Models data and yet the View
functions are not placed in the class. Abstractly, any function could
be thought of as a view function, even if it does not draw a
representation of the object. This could lead one to conclude that if
a function does not change an object’s state, then it should always
reside outside the object and query the object for data, just like a
View object. Fat classes generally are not considered good design, so
I was trying to envision what it would be like to have very thin
classes, containing only functions that modify state. Writing all the
accessors seemed awkward though. I suppose as always there are no
hard fast rules and comprises are required.

It’s a tough problem and I’m not sure there is one style that works for
all languages. My C++ classes are very thin and I can tell you why
every member function couldn’t have been implemented without access to
the object’s state. My Ruby and ObjC classes tend to be fatter. Why? I
suppose it’s a combination of making membership serve some of the
function of namespaces, for ObjC, and some feeling that the contract is
just different in languages where classes are closed as opposed to
those where they are open. I keep half expecting all my Ruby and ObjC
code to come crashing down because encapsulation is more like a
membrane than a wall. So far it hasn’t happened though. It’s as if it’s
enough to describe the safe interface to a class without requiring the
language to enforce the exclusive use of that interface.

The responses above brought me back to a more concrete reality. MVC is
there to separate out user interface code. It is also true, that I
did not understand the roll of the controller. Thinking of a passive
Model and a passive View has also helped me with my current problem.

Perhaps it is wise to pull functions out of a class along functional
lines that require specialized developer skills such as GUI, Database
Access, Encryption, etc. Or maybe it only makes sense for GUI,
because, of the need to easily change the GUI.

I think you are on to something here.

···

On Monday, September 16, 2002, at 03:32 PM, MetalOne wrote:

We are all born originals - why is it so many of us die copies?
-Edward Young, poet (1683-1765)

9

jcb@iteris.com (MetalOne) writes:

Thanks to all for your help.

I was really thinking very abstractly about a problem in my head that
MVC kind of demonstrated. I was in search of deep answers in regards
to when to include a function in a class and when not too. The common
wisdom states that when a function needs access to the classes data,
it should be included with the class. MVC strays from this notion
because the View needs access to the Models data and yet the View
functions are not placed in the class.
That is not true. the view does know nothing about the Model the only
one which knows of it is the Controller. But you have to provide all
the access functions a Controller may need in both the View and the
Model. I’ll try to show a simple example (not Ruby)

Modell
a number a
a number b

model work is
add a b

View
a textfield a_number
a textfield b_number
a output field c_number

accessors to a_number b_number
setter for c_number

Controller
Model class
View class

Controller get data from View
    query the content of the view
    my_a = View.get_textfield_a_content
    my_b = View.get_textfield_b_content
ask the model do it's work out the work
my_sum = Model.add(a, b);

update the view
View.set_c_number(my_sum)

…

You can write that example down nearly one-to-one in Ruby. You just
have to to know the Ruby GUI classes. But you see it fit’s perfectly
into the OO model. Controller does not know about the inners of both
it just uses the official available interface provided by Model, but
the view and the Model do not know anything from each other. All this
knowledge is bundeled in the Controller.

I hope this clarifies it.
Regards
Friedrich

10

jcb@iteris.com (MetalOne) writes:

Thanks to all for your help.

I was really thinking very abstractly about a problem in my head that
MVC kind of demonstrated. I was in search of deep answers in regards
to when to include a function in a class and when not too.

Ok now after a an abstract example an fully fledged Ruby MVC
application. I’ve used ruby-gnome and

This is the application code
require ‘lglade’

class Controller
def initialize
@glade = GladeXML.new(“mvc_ruby.glade”){|handler| method(handler)}
@tf_1 = @glade.widget(“tf_number_one”)
@tf_2 = @glade.widget(“tf_number_two”)
@sum_field = @glade.widget(“tf_sum”);
@model = Model.new
end

def on_pb_calculate_clicked(widget, data)
@sum = @model.add(@tf_1.get_text.to_f, @tf_2.get_text.to_f)
@sum_field.set_text(@sum.to_s)
end

def quit
Gtk.main_quit
end

end

class Model
def add (a, b)
return a + b
end
end

Controller.new
Gtk.main

The view is not seen as a extra class text here it’s hidden behind the
@glade instance variable that’s my View!

The .glade stuff is this (very fast thrown together, so please be
aware:
But please be aware too where the connection occures.

  • the names for the textfields
  • and the callback functon (enclosed in …)

This is what I would see as “exported” from the View.

I do not claims this to be excelleent ruby programming but I hope it
shows that MVC and OO do not fight each other. What could be improved
the
@tf_1.somethi.to_f chain is not nice one, one could hide it behin
another function. But you are invited to do it better than me :wink:

<?xml version="1.0"?> MVC_ruby mvc_ruby src pixmaps C True True GtkWindow main_window MVC Example in Ruby GTK_WINDOW_TOPLEVEL GTK_WIN_POS_NONE False False True False GtkVBox vbox1 False 0 
<widget>
  <class>GtkHBox</class>
  <name>hbox4</name>
  <homogeneous>False</homogeneous>
  <spacing>0</spacing>
  <child>
<padding>0</padding>
<expand>True</expand>
<fill>True</fill>
  </child>

  <widget>
<class>GtkLabel</class>
<name>label4</name>
<label>Zahl 1</label>
<justify>GTK_JUSTIFY_CENTER</justify>
<wrap>False</wrap>
<xalign>0.5</xalign>
<yalign>0.5</yalign>
<xpad>0</xpad>
<ypad>0</ypad>
<child>
  <padding>0</padding>
  <expand>False</expand>
  <fill>False</fill>
</child>
  </widget>

  <widget>
<class>GtkEntry</class>
<name>tf_number_one</name>
<can_focus>True</can_focus>
<editable>True</editable>
<text_visible>True</text_visible>
<text_max_length>0</text_max_length>
<text></text>
<child>
  <padding>4</padding>
  <expand>False</expand>
  <fill>False</fill>
  <pack>GTK_PACK_END</pack>
</child>
  </widget>
</widget>

<widget>
  <class>GtkHBox</class>
  <name>hbox5</name>
  <homogeneous>False</homogeneous>
  <spacing>0</spacing>
  <child>
<padding>0</padding>
<expand>True</expand>
<fill>True</fill>
  </child>

  <widget>
<class>GtkLabel</class>
<name>label5</name>
<label>Zahl 2</label>
<justify>GTK_JUSTIFY_LEFT</justify>
<wrap>False</wrap>
<xalign>0.5</xalign>
<yalign>0.5</yalign>
<xpad>0</xpad>
<ypad>0</ypad>
<child>
  <padding>4</padding>
  <expand>False</expand>
  <fill>False</fill>
</child>
  </widget>

  <widget>
<class>GtkEntry</class>
<name>tf_number_two</name>
<can_focus>True</can_focus>
<editable>True</editable>
<text_visible>True</text_visible>
<text_max_length>0</text_max_length>
<text></text>
<child>
  <padding>4</padding>
  <expand>False</expand>
  <fill>False</fill>
  <pack>GTK_PACK_END</pack>
</child>
  </widget>
</widget>

<widget>
  <class>GtkHBox</class>
  <name>hbox6</name>
  <homogeneous>False</homogeneous>
  <spacing>0</spacing>
  <child>
<padding>0</padding>
<expand>True</expand>
<fill>True</fill>
  </child>

  <widget>
<class>GtkLabel</class>
<name>label6</name>
<label>Sum</label>
<justify>GTK_JUSTIFY_CENTER</justify>
<wrap>False</wrap>
<xalign>0.5</xalign>
<yalign>0.5</yalign>
<xpad>0</xpad>
<ypad>0</ypad>
<child>
  <padding>4</padding>
  <expand>False</expand>
  <fill>False</fill>
</child>
  </widget>

  <widget>
<class>GtkEntry</class>
<name>tf_sum</name>
<can_focus>True</can_focus>
<editable>True</editable>
<text_visible>True</text_visible>
<text_max_length>0</text_max_length>
<text></text>
<child>
  <padding>4</padding>
  <expand>False</expand>
  <fill>True</fill>
  <pack>GTK_PACK_END</pack>
</child>
  </widget>
</widget>

<widget>
  <class>GtkButton</class>
  <name>pb_calculate</name>
  <can_focus>True</can_focus>
  <signal>
<name>clicked</name>
<handler>on_pb_calculate_clicked</handler>
<last_modification_time>Tue, 17 Sep 2002 06:16:34 GMT</last_modification_time>
  </signal>
  <label>Calculate Sum</label>
  <relief>GTK_RELIEF_NORMAL</relief>
  <child>
<padding>5</padding>
<expand>False</expand>
<fill>False</fill>
  </child>
</widget>

Very verbose this XML isn’t it ;-(

Regards
Friedrich

11

jcb@iteris.com (MetalOne) writes:

Thanks to all for your help.

I was really thinking very abstractly about a problem in my head that
MVC kind of demonstrated. I was in search of deep answers in regards
to when to include a function in a class and when not too. The common

wisdom states that when a function needs access to the classes data,
it should be included with the class. MVC strays from this notion
because the View needs access to the Models data and yet the View
functions are not placed in the class.

Yes, that is true. This is because, you might have multiple views on
the model, so the functionality has to be separated in to differnet
classes.

The responses above brought me back to a more concrete reality. MVC is

there to separate out user interface code. It is also true, that I
did not understand the roll of the controller. Thinking of a passive
Model and a passive View has also helped me with my current problem.

Perhaps it is wise to pull functions out of a class along functional
lines that require specialized developer skills such as GUI, Database
Access, Encryption, etc. Or maybe it only makes sense for GUI,
because, of the need to easily change the GUI.

What I personally go by is to keep functions to the class that has the
data. That is until this becomes troublesome. Troublesomeness might
come from the class being difficult to test becuase it paints on the
screen, accesses a relational database and similar things. The class
in other words becomes difficult to work with because it does too many
things. This leads to layering where you move the methods that access
f.ex the database to a class that deals with the database, move gui
methods to views and so on.

···

–

Vennlig hilsen

Syver Enstad

12

“MetalOne” jcb@iteris.com wrote in message
news:92c59a2c.0209161426.5a777753@posting.google.com…

Thanks to all for your help.

I was really thinking very abstractly about a problem in my head that
MVC kind of demonstrated. I was in search of deep answers in regards
to when to include a function in a class and when not too. The common

Initially I found the tricky part to decide between inhertance and
aggregation, leaning towards aggregation.
That was C++, now single inheritance languages like Java and Ruby makes this
choice easier as you often have to go with aggregration. Aggregation leads
to more effort in mirroring aggregated functionality to the aggregating
class. How to avoid this? Use Ruby Mix’ins.

I’m no longer so interested in OO design - either it is obvious and you
just do it - or the interaction becomes too complicated and it is better
abstract out in components. Too complex object interaction isn’t good. The
difference between components and objects are not clear, but generally
components are more loosely coupled. Like require a ruby package that
internally has more objects than you care about.

Hence my focus is on component interfaces. Dealing with published
functionality, lifetime management across interfaces, handling of
identifiers across interfaces. These are challenging issues. (And the fact
that Ruby makes this comparitively easy is a significant part of Ruby’s
power - take distributed Ruby as an example and compare the effort going
into DCOM/Corba).

Most benefit I’ve seen in Ruby has actually little to do with classes and
more its functional nature. The essential problem with pure functional style
is that it is difficult to subsequently add an extra piece of information to
the set of interacting functions. Objects become a good way to contain a
concept. Like a coordinate object that later needs precision added.

In the end it is a question of - how can I easily access data without
becoming too dependent on changes in implementation. Some solves this by
brain-dead refactoring. Refactoring is a good tool, but not a design tool.

You control this complexity be choosing a component interface abstraction.
Then I’m less concerned with what is behind the component interface because
it is not more complex than what refactoring allows and the OO design
choices essentially becomes - how can I most easily do this job.

wisdom states that when a function needs access to the classes data,
it should be included with the class. MVC strays from this notion
because the View needs access to the Models data and yet the View
functions are not placed in the class.

Unless you are hooking into a framework or building one, you don’t (IMO)
need to think too hard about the separation between model view and
controller - instead it is better to study the actual flow of information
and build objects that most easily represent this. You won’t add a new
totally indendependt view type later on that just plugs in neatly - it
doesn’t happen that way. But if you have a clean structure that does not
work against your information flow, it should be easy to extend whether it
conforms to a specific concept such as MVC or not. Perhaps this pragmatism
only comes with experience and as such it may be good to follow a guideline.

classes, containing only functions that modify state. Writing all the
accessors seemed awkward though. I suppose as always there are no
hard fast rules and comprises are required.

Certainly. I’m really don’t like looking at pages and pages of Java code
doing nothing but setting and getting data - it’s good to protect you data
access, but you could have done it at a larger granularity.
I’ve seen some horribly bloated code where you can search the source for
hours without being able to locate where exactly the logic is happening
because everything is about data hiding and making baseclasses for
everything as if you would ever implement those ten different versions of
the same thing. (I’ve to some extend done so myself - I’m just bailing out
now).

There is no rulebook - the objective is clean, understandable and
maintainable code that can also be implemented in reasonable time.

Perhaps it is wise to pull functions out of a class along functional
lines that require specialized developer skills such as GUI, Database
Access, Encryption, etc.

That’s what you could call component interfaces, and I agree - except it has
nothing to do with developer skills but with functionality. About seperating
out things that can be separated in order to decrease complexity.

Or maybe it only makes sense for GUI,
because, of the need to easily change the GUI.

A (G)UI is rather much a consumer of other entities as those you mention
above. I.e. A GUI is on “the other side” of the interfaces and orchestrates
what should happen when, whereas the component interfaces should just
deliver (that does not prevent a push model, but still someone decides when
to request for having data pushed).

Mikkel

13

Friedrich Dominicus frido@q-software-solutions.com writes:

jcb@iteris.com (MetalOne) writes:

Thanks to all for your help.

I was really thinking very abstractly about a problem in my head that
MVC kind of demonstrated. I was in search of deep answers in regards
to when to include a function in a class and when not too.

Ok now after a an abstract example an fully fledged Ruby MVC
application. I’ve used ruby-gnome and

This is the application code
require ‘lglade’

class Controller
def initialize
@glade = GladeXML.new(“mvc_ruby.glade”){|handler|
method(handler)}
sorry, small glitch
@window = @glade.widget(“main_window”)
@window.signal_connect(‘destroy’){quit}

One chould clean up after one’s work is done.

Friedrich

14

Friedrich Dominicus frido@q-software-solutions.com wrote in message news:87hegq5wes.fsf@fbigm.here…

This is correct the Modell notifies the Controller or the other way
round the Controller queries the modell for needed input

Hum, there are some different views of what a controller
is or how the M, V and C should look like. They are much
influenced by the GUI-framework one uses or the overall
architecture which should be built.
Therefore MVC is in modern reading not named a ‘pattern’
any more but a ‘paradigm’ (and everytime causes a lot of
discussion in developer teams).

As with the classical view IMHO there is a triangle
between M,V and C. So the Modell notifies the View, not
the Controller.
The Controller does not query the Model per Design.
(This is only a hidden technical aspect, if necessary to
do his job).

forwards it
to the Model get back the values from the Model and than
updates the View.

The Controller does not update the View in the above
mentioned scenario. The View (displaying part of a GUI)
updates itself (ok, based on push or pull …).
The Controller updates the Model caused by events
coming from the GUI-Controls (User).

In some frameworks (Java too) there is a tight coupling
between Controller and View, as the Controllers are
ActionControllers, listening to GUI-Events sent by
GUI-Components directly. So a GUI-Component is a
displaying (View-)Component and an event trigger
for controllers at the same time.
But by that way resizing a window, leaving a text field
or saving a dataset (Model) is not really different.

If you write a standalone GUI-only Application this
can be a meaningful way to make things work.

But there is a more general view too, e.g. used in
distributed environments. There the Model is an object
net used for persistence purposes and is indeed queried
by the Controller. The Controller rather reacts on more
coarse grained Business Events than on single mouse clicks
and is mentioned to implement Business Processes. This can
also be the start of a subcontroller with a specific View
(a GUI-Frame, Window or similar).

Instead of reacting to Business Events the Controller
can also be implemented to provide Business Services
called by clients, no matter if they are GUIs, scripting
engines, 3rd party products using an API-Library …
The Controller then is the only connection between View
and Model, as it provides the Model query for the View
too.

So thinking in terms of MVC the whole application can
appear like a hologram (or a fractal picture) showing
a general MVC structure where parts of it build a
MVC structure again.
(coarse grained: Model as persistent object net,
Controller as service provider classes, View as all
kind of clients.
fine grained look into the Model:
classes in the memory as View, tables in the
database as Model, the mapper functionality of either
a tool or a RDBMS, or whatever as Controller.
fine grained look into the GUI:
GUI components as View, event listener as Controller,
client-side representation classes as Model).

Bye
Det

15

ddet@gmx.de (Det) writes:

Friedrich Dominicus frido@q-software-solutions.com wrote in message news:87hegq5wes.fsf@fbigm.here…

This is correct the Modell notifies the Controller or the other way
round the Controller queries the modell for needed input

Hum, there are some different views of what a controller
is or how the M, V and C should look like. They are much
influenced by the GUI-framework one uses or the overall
architecture which should be built.
Therefore MVC is in modern reading not named a ‘pattern’
any more but a ‘paradigm’ (and everytime causes a lot of
discussion in developer teams).
Thanks for the clarification. I probably did understand it
differently.

As with the classical view IMHO there is a triangle
between M,V and C. So the Modell notifies the View, not
the Controller.
Well I posted an example, why don’t you do the same as how you see it?
It would be helpful for discussion. I don’t think that I agree with it
because with that I do get a sort of coupling between the View and the
Model.
The Controller does not query the Model per Design.
(This is only a hidden technical aspect, if necessary to
do his job).
Well for me that is the point. The controller sit’s in the middle,
waiting for things to come. If the Model changes it request the View
to update to the new standard. But the Model doesn’t knwo anything
from the view…

forwards it
to the Model get back the values from the Model and than
updates the View.

The Controller does not update the View in the above
mentioned scenario. The View (displaying part of a GUI)
updates itself (ok, based on push or pull …).
The Controller updates the Model caused by events
coming from the GUI-Controls (User).
Well could you show what you mean in code?

Regards
Friedrich

16

I seen this notion of a “triangle” in some of the early explication of
MVC but it’s always seemed to be a case of Sapir-Worff in action. The
Smalltalk programmers who talk about this case correctly note that
sometimes the model is volatile from the POV of the user because the
program is responding to messages that are coming from elsewhere; the
system, the network, or another user. The Smalltalk guys were stuck in
a single inheritance world so they tried to overlay a
notification/subscriber pattern on top of MVC and came up with this
triangle variant.

IMHO, that’s not the Ruby way. With Mixins one can set up a
notification system that reasonably orthogonal to the MVC structure of
the app. Much cleaner.

···

On Tuesday, September 17, 2002, at 02:33 AM, Det wrote:

Friedrich Dominicus frido@q-software-solutions.com wrote in message
news:87hegq5wes.fsf@fbigm.here…

This is correct the Modell notifies the Controller or the other way
round the Controller queries the modell for needed input

Hum, there are some different views of what a controller
is or how the M, V and C should look like. They are much
influenced by the GUI-framework one uses or the overall
architecture which should be built.
Therefore MVC is in modern reading not named a ‘pattern’
any more but a ‘paradigm’ (and everytime causes a lot of
discussion in developer teams).

As with the classical view IMHO there is a triangle
between M,V and C. So the Modell notifies the View, not
the Controller.

The higher we soar the smaller we appear to those who cannot fly.
-Friedrich Wilhelm Nietzsche, philosopher (1844-1900)

17

Hi,

Just an aside, in skimming this thread I remembered some of the Smalltalk
folk talking about having moved on to Model View Presenter from MVC…

Google came back with hits (as usual :wink:

http://www.object-arts.com/EducationCentre/Overviews/MVC.htm
The former explains MVC, and deficiencies they’ve addressed by moving to:
http://www.object-arts.com/EducationCentre/Overviews/ModelViewPresenter.htm

HTH,

Bill

18

It does, Bill. I think when people say MVC they mean something much
closer to what object arts is calling MVP.

···

On Tuesday, September 17, 2002, at 08:52 AM, Bill Kelly wrote:

Hi,

Just an aside, in skimming this thread I remembered some of the
Smalltalk
folk talking about having moved on to Model View Presenter from
MVC…

Google came back with hits (as usual :wink:

http://www.object-arts.com/EducationCentre/Overviews/MVC.htm
The former explains MVC, and deficiencies they’ve addressed by moving
to:
http://www.object-arts.com/EducationCentre/Overviews/
ModelViewPresenter.htm

HTH,

–
We are all born originals - why is it so many of us die copies?
-Edward Young, poet (1683-1765)