Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.gui > #4802

Re: MVC - simplified?

From Daniel Pitts <newsgroup.nospam@virtualinfinity.net>
Newsgroups comp.lang.java.gui
Subject Re: MVC - simplified?
References <MVC-20111206170519@ram.dialup.fu-berlin.de>
Message-ID <4tsDq.13109$LO2.3676@newsfe13.iad> (permalink)
Date 2011-12-06 09:41 -0800

Show all headers | View raw


On 12/6/11 8:23 AM, Stefan Ram wrote:
>    When is it sensible to simplify MVC for small GUI applications?
*Never,  Inline comments below, but see footnote.
>
>    What about the following simplifications:
>
>    * Do not de-couple the model from the view via the observer
>    pattern in cases where the view and model are quite fixed,
>    so that no pluggability for the view is needed: The model
>    knows the view and calls the view directly when needed.
You do this only if you want strange artifacts to appear due to 
incompatibility with your painting code and the Swing/Awt painting 
processes.  There is a way to set up "direct" mode applications. I think 
it is for full screen only, but it does allow you to paint how and when 
you want.
>
>    * Do not formally separate M, V, and C into separate
>    classes or packages, but use a single big »monster class«
>    for the main program that contains M, V, and C. (However,
>    comments or methods might be used to indicate which parts of
>    this class belong to the realm of M, V, or C.)
You can do this if you want to throw away the program and never look 
back.  It has been my experience that anything worth writing this way is 
worth writing it with a clearer separation.
>
>    The advantage of this approach is that it saves the effort
>    for the specification and implementation of interfaces and
>    the administration effort for the registration and
>    de-registration of listeners. It does not exclude a later
>    refactoring that than will implement more separation and
>    decoupling, when needed.
>
>    And regarding monster classes: It might sound provocative:
>    I am aware of a 64 K limit on method size, is there a known
>    limit on class size (like at most 100 methods, or or some
>    such)?
>
>    BTW: Did the pattern »MVC« actually ever require that the
>    model, view, and controler are separate objects or classes,
>    or does it also allow for them to be mixed within the same
>    object or class - or even the same method or statement?
>

Nothing requires separate classes or objects, but the pattern itself is 
useful in clarifying your ideas.  Even if you have a monster class, you 
should have "controller" methods, "model" fields/methods, and "view" 
methods.  Now, any time you have a class that can be split that way, it 
is time to consider moving them to separate classes. Kind of like 
factoring an equation. It just makes it easier to deal with in the long run.

Its not that you should strive to make an MVC, its that you *are* making 
an MVC and you should strive to keep each part coherent, as one should 
strive to keep *all* their code coherent.

* "Never" or "always" really mean "unless it would make a monstrosity."

HTH,
Daniel.

Back to comp.lang.java.gui | Previous | NextNext in thread | Find similar


Thread

Re: MVC - simplified? Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2011-12-06 09:41 -0800
  Re: MVC - simplified? Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2011-12-06 10:10 -0800

csiph-web