Re: MVC - simplified?
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
* 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
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."