IMHO if you're out for a clean solution and there is no easy common
functionality that you can use for displaying (i.e. toString() or a method
getStatus() that's defined in the base class and probably overriden in sub
classes) you need the mirrored class hierarchy.  You could use a
Map<ModelClass, ViewWrapperClass> to look up the class that you need to
instantiate at Runtime as wrapper.

My 0.02 EUR...

   robert

Snippage.

You don't have to put the view logic in model subclass hierarchy, but
there's nothing wrong with having the *selection* of a particular view
interface in the model subclass hierarchy.

A la:
class TruckModel {
  go() {
     ViewFacade view = registry.getViewFacade();
     ThingPresentation thing =
viewFacade.getPresentation(ViewFacade.BIG_THING);
     thing.draw();
  }
}

class CarModel {
  go() {
     ViewFacade view = registry.getViewFacade();
     ThingPresentation thing =
viewFacade.getPresentation(ViewFacade.SMALL_THING);
     thing.draw();
  }
}

.ed

--
www.EdmundKirwan.com - Home of The Fractal Class Composition

Sounds like the sort of problem the visitor pattern aims to solve.

Tom Hawtin

Then you have got yourself into a slight tangle, and must expect to use more
tangled logic to get out of it again.

What you have is an architecture where the various possible models are /not/
mutally substitutable, but where you are trying to treat them as if they are.
So, /somewhere/, you will need to have logic that breaks the classical MVP/MVC
rules.

Some options:

Something must have created the model.  You could require that also to "know"
the correct corresponding view type.  (This is roughly the same as John's
suggestion).

You could use a lookup table to map model types to view types (Robert's
suggestion).

You could make the model aware of what the corrrect corresponding view type is
(note that this is not classical MVC, but but it nevertheless does not break
the more important rule that the model does not depend on, any /specific/ view
instances that may be connected to it).

If you build the view dynamically, then the model could be required to "know"
what aspects it has that are available for
displaying/printing/rendering/observing/etc.  You construct a view instance
based on that data.

   -- chris