MVC - simplified?
When is it sensible to simplify MVC for small GUI applications?
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.
* 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.)
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?