多态视图的模式
想象一下我有一个抽象的“FriendEvent”模型，它有几个不同的具体实现，即。 FriendPosted、FriendCommented、FriendUploadedPhoto 等。它们都应该在我的 FriendEvents 视图中呈现，但在视觉上应该彼此不同（例如 FriendUploadPhoto 应包含缩略图）。
什么是一个好的面向对象模式来实现这一目标？
我有兴趣了解是否有其他方法可以在视图代码中打开模型的具体类。这在某种程度上感觉不对，因为它使用条件逻辑，我认为应该可以依赖多态性，但我很难想出更好的主意。有没有既定的模式来处理这个问题？
（我显然不想在模型中实现视图逻辑，因为这会混合职责，并且因为我可能希望每个模型有不同的视图）
澄清：如何对模型中的不同事件类型进行建模层不是问题。有几种众所周知的 OO 解决方案。问题涉及负责以视觉方式呈现模型的视图代码。我想我有一个 EventView 类，用于处理显示事件（模型）。问题是：如何在没有开关块的情况下实现此类，该开关块根据渲染的事件的具体类型选择不同的代码路径。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
似乎您在这里有一些 DoubleDispatch 问题。
如果我理解正确的话，您正在努力避免混合模型和视图。每个事件类都可以有，
但所有事件都有视图知识，每次我们添加一种新的视图时，我们都会添加一个新的 getXXXView() 方法。我同意这看起来令人不愉快。
因此，我们可以通过让所有事件提供来增加关注点分离
。现在至少我们已经将视图代码放到了它自己的类中。是的，我们可能需要为每种/多种事件编写特殊情况代码，但这是不可避免的。我们的第一个问题是在哪里放置特殊代码 - 我们已经找到了答案。
然而我们仍然有一个问题：每种新的 View 都需要一个新的 getXxxMaker 方法。所以我们开始研究更复杂的工厂以及泛型和模板的使用等等。
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
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
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.
对我来说，我只会使用部分视图概念。基类由主视图处理，并且该主视图需要一个分部视图来满足显示具体类的需要。
For me, I would just use the partial-view concept. The base class is dealt with by the primary view, and that primary view requires a partial view that takes care of the needs of displaying the concrete class.