Question

Imagine I have a abstract “FriendEvent” model which has several different concrete implementations, ie. FriendPosted, FriendCommented, FriendUploadedPhoto etc. They should all be rendered in my view of FriendEvents, but should be visually distinct from each other (e.g. FriendUploadPhoto should include a thumbnail).

What is a good object oriented pattern to achieve this?

I’m interested to learn if there’s an alternative to switching on the concrete class of the model in the view code. That somehow feels wrong because it uses conditional logic where I believe it should be possible to rely on polymorphism, but I have a hard time thinking up a better idea. Are there any established patterns to deal with this?

(I obviously don’t want to implement the view logic in the model, since that would be mixing the responsibilities, and since I may want to have different views for each model)

To clarify: How to model the different event type in the model layer is not the problem. There are several well known OO solutions. The question concerns the view code which is responsible for presenting the models visually. I imagine I have an EventView class which deals with showing an event (model). The question is: How to implement this class without a switch block that selects a different code path depending on the concrete type of Event is is rendering.

Answer 1

Seems like you have some DoubleDispatch concerns going on here.

If I understand you correctly, you are trying to avoid mixing Model and View. Each Event class could have

HtmlString getHtmlView() { /* code */ }

but then all events have view knowledge and each time we add a new kind of view we add a new getXXXView() method. I agree that this sees unpleasant.

So we could increase the separation of concerns by having all events offer

HtmlViewMaker getHtmlMaker {  return new MyKindOfViwer(this); }

Now at least we’ve got the View code out into its own class. Yes we may well need to write special case code for each/many kinds of events, but that’s inevitable. Our first problem is where to put that special code – and that we’ve an answer for.

However we still have a problem: each new kind of View needs a new getXxxMaker method. So we start to look at more complex Factories and the use of Generics and Templates and so on.