Re: Hairy generics question
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<Screen, Handler> handlers = loadHandlerMap();
private final Map<Screen, Map<Outcome, Screen>> 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