Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!news.albasani.net!.POSTED!not-for-mail From: Lew Newsgroups: comp.lang.java.programmer Subject: Re: Hairy generics question Date: Tue, 28 Feb 2012 12:45:29 -0800 Organization: albasani.net Lines: 79 Message-ID: References: <3c65271e-a388-49c9-bcc6-ca3bf274e74f@e27g2000vbu.googlegroups.com> <29108397.63.1330110725245.JavaMail.geo-discussion-forums@vbpw21> <7822487.176.1330121248108.JavaMail.geo-discussion-forums@vbkl3> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news.albasani.net 3EngH0499bdPQ7ApkRP1a5fSGbW1HKh0JqDymst8vNLHSL0iZVeXbp1MpM+Ks+paGXOspqXk6LnH3Er1FmjPCr/CVrSY0PeXrFRSU4cio1zjIoK59aWZPaIegVxOAEvM NNTP-Posting-Date: Tue, 28 Feb 2012 20:45:22 +0000 (UTC) Injection-Info: news.albasani.net; logging-data="UKLs4njO3mMWVwTzWMsOXhUSQFn/IMm3Oy94Jw6iqjjZFbh+vrlqmlKmex1c8M+X/Tgnc5e1l22vhsrt0NdZ9+ztYQPvbYpsEsFwje/Dhmt1GvAL5Dhh1V3ByibAgGoC"; mail-complaints-to="abuse@albasani.net" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 In-Reply-To: Cancel-Lock: sha1:plfOdK4l3RzwcCXtWJ/murciRKc= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:12501 Daniel Pitts wrote: > I've just read the original Taligent, Inc. PDF on what MVP is, and it looks > like its little more than a clarification of MVC, with some new concepts > pulled out. Things that were inferred in the "controller" are now their own > concepts. Other references make a similar point, or conversely take great pains to distinguish MVP (most valuable player) from MVC. Such care would be unnecessary were the concepts actually so different. "MVC" is a pretty loose term, which accounts for some of the controversy. In large terms it means no more than "model-view-controller" and the principle of separation of concerns imply. Really, the taxonomy dispute is by the wayside. Personally, I recognize "MVC" as the species, like the first "lupus" in "canis lupus lupus", and subspecies, like the second "lupus". Then "MVP" would be another subspecies, like the "familiaris" in "canis lupus familiaris". Life - Domain - Kingdom - Phylum - Engineering - Computer - Software - Programming - Class - Order - Family - Genus - Species - Sub Architecture - Patterns - Modular - Acyclic - MVC - MVC Architecture - Patterns - Modular - Acyclic - MVC - MVP So MVC is the wolf, and MVP the dog. That's just an offhand metaphor, a "Lewnnaeus" classification, if you will. Perhaps it will help some of you. > In that case, my original advice still stands. View shouldn't know about the > Presenter, only about the Model, and event listeners. The Model shouldn't know > about the View or Presenter, only about observers, and the Presenter is > basically knows about everything. > > As such, you can't easily have a Generic Presenter. Also, as such, you needn't > have the view have any information about the "type" of the Presenter. The View > also only needs the interface type of the Model, not the specific type. The > Model needs only to know only interface types as well. > > This allows you to completely remove the circular type dependencies, which is > one of the main benefits of MVC and MVP architectures in the first place. The pattern itself is acyclic, which accounts for how it accomplishes that: "knows about": P |- V |- M |- M This translates almost directly into type dependencies. I don't usually make the Controller (or Presenter) generic. It works just fine with non-generic 'Screen' (a View artifact) and 'Handler' types sorta like this (pseudocode): public class Controller { static enum Outcome {SUCCESS, FAILURE, ERROR}; private final Map handlers = loadHandlerMap(); private final Map> navigations = loadNavigations(); public void process(Request request, Response response) { Screen screen = request.getScreen(); Handler handler = handlers.get(screen); Outcome outcome = handler.handle(request, response); Screen next = navigations.get(screen).get(outcome); forward(next, request, response); } // etc. } Of course, this is just one way to do the pattern. It's what I use for Web apps if I'm hand-rolling, and not dissimilar to how Struts does things; however, I've been doing this since before Struts was available. -- Lew Honi soit qui mal y pense. http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg