观察以下类及其包含:
Section
有一个ItemList
有很多Item
s
但是让我们说一个Item
基于一些复杂的算法被渲染为不同的颜色,该算法基于Section.name
它所包含的。
抽象此功能的正确/最佳方法是什么?在这样的情况下是否存在常见的设计模式?还是固有的设计有缺陷?
观察以下类及其包含:
Section
有一个ItemList
有很多Item
s
但是让我们说一个Item
基于一些复杂的算法被渲染为不同的颜色,该算法基于Section.name
它所包含的。
抽象此功能的正确/最佳方法是什么?在这样的情况下是否存在常见的设计模式?还是固有的设计有缺陷?
您应该将数据结构/模型与逻辑和处理分开。也就是说,我会让你的 Item 有一个Section
引用 it's 的引用Section
,当你将 an 添加Item
到 时ItemList
,确保 add 方法查看ItemList
s Section
(父级)并将引用设置在Item
. 中的设置器也是如此ItemList
,Section
它必须迭代每个Item
并设置Section
.
或者,您可以在惰性语义Section
的 getter 上进行设置ItemList
,这完全取决于您的使用情况Section
,这两种方法之间的性能统计信息会有所不同。
此外,我会编写某种形式的渲染器,它采用Item
并知道如何渲染它,它会查看Section
on theItem
和 the Name
on that Section
。
您可能想要渲染整个部分,但我会单独编写该渲染器,它会使用ItemRenderer
来渲染每个Item
.
顺便说一句,您可能希望使用一种形式IObservableCollection
并拥有该Item
工具INotifyPropertyChanged
,以便您可以保持渲染版本和项目之间的同步,并通过更新属性的事件注册Item
与Section
它存在的同步Section
适当地。
渲染是做什么的?如果它在Section
所有这些中或之外,但是从 s 访问Item
s Section
,那么就不需要更多了。
如果它在 中Item
,那么您只需要确保Item
知道Section
它属于什么,或者可以获得它(例如,通过拥有一个它可以查找的 ID - 对于那些使处理循环引用变得棘手的语言很有用,但在其他方面没有不必要的麻烦) .
由于第一种情况不会造成任何困难,显然它优于第二种情况,因此最接近设计模式的是,如果您发现自己在包含的项目中进行此类工作,请尝试将其移动到容器中,或在它们之外。除此之外,没有太多需要解决的问题。
我会构建一个ItemRenderer
知道算法的类,并将引用传递给Item
您想要渲染的每个以及Section
它包含在其中的引用。
让每个人都Item
知道它所属的部分可能也很有意义,但我仍然会让ItemRenderer
处理渲染。