Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.gui > #4802
| 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 |
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 | Next — Next in thread | Find similar
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