对于这种分层类结构来说，合适的设计模式是什么？
我有一个实例化类层次结构的类。接口应该通过呈现单个类引用来隐藏所有内部层次结构。 （中间级别的类的接口应该以同样的方式隐藏内部实现细节。）我在决定如何将接口参数向下传递到最低级别以及将状态更改向上传递到顶层时遇到了一些困难。我想出的东西变得混乱。
我看过一些关于黑板模式的讨论，但是，从我所看到的来看，它看起来是临时的、扁平的，而不是分层的。 （尽管平面与分层可能并不重要。）
我拥有的类是日历视图，是 UIView 的子类。该层次结构包括标头类、网格类（实例化多次）、图块类（实例化多次）以及一些辅助类。它基于 Objective C 中 Keith Lazuka 的 kal 日历。我决定根据我的需要重新组织它，并想在引入灵活性问题之前重新考虑这部分。
我的问题就在标题里。
I have a class that instantiates a hierarchy of classes. The interface should hide all of the internal hierarchy by presenting a single class reference. (An the interface to the classes at intermediate levels should hide internal implementation details the same way.) I am having a little difficulty deciding how to flow the interface parameters down to the lowest levels and to flow state changes up to the top level. What I have come up with gets messy.
I have seen some discussions of the blackboard pattern but, from what I have seen, it looks ad hoc and flat rather than hierarchical. (Although flat vs hierarchical may not be important.)
The class I have is a calendar view, subclasing UIView. The hierarchy includes a header class, a grid class (instantiated more than once), a tile class (instantiated many times), plus some helper classes. It's based on Keith Lazuka's kal calendar in Objective C. I've decided to reorganize it for my needs, and wanted to rethink this part of it before I introduce problems with flexibility.
My question is in the title.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为 KVO（键值观察者）设计模式对于从较低级别到顶部冒泡状态信息是有意义的。在每个相应层仅观察到需要向上流动的状态信息。
在此应用程序中，点击的图块事件被发送到上一层（网格层）的观察者，告诉它用户已经选择了一个日期，这是图块类的属性。
在网格级别，它根据其当前状态和观察者从图块接收到的新信息来更改其状态。 （在我的日历中，用户可以通过选择开始日期和结束日期来选择日期范围，并且可以继续点击图块来更改他的日期范围选择。）这种网格级别的状态更改会转化为开始和/或结束日期的更改。或结束日期，因此 NSDictionary 属性被更新。
在日历级别，观察者会看到 startDate/endDate 字典发生变化。无论它来自哪个网格（有两个网格，并且一次只有其中一个处于活动状态。磁贴和日历不需要意识到这一点），日历的开始日期和结束日期都会更新。
日历是一种嵌入到应用程序的其他视图之一中的视图，用要显示的月份和选定的日期范围（开始日期和停止日期）进行初始化。信息通过指向任何层的每个直接子视图的指针从顶部向下流动。这些子视图负责保持其子视图的配置。我不再需要显式添加委托方法或回调，这简化了从上到下的连接。连接仅进入层次结构中的上层或下层直接层。
这看起来可能并不多，因为它看起来相当简单。但直到我花了一段时间思考之后才明白。我希望它能给其他人一些关于他们自己的代码的想法。我仍然想知道是否还有其他建议可以回答我的问题。
I have decided that the KVO (Key Value Observer) design pattern makes sense for bubbling state information from the lower levels to the top. Only that state information that needs to flow up is observed at each of the corresponding layers.
In this application, a tapped tile event is sent to the observer at the next level up (the grid level), telling it that the user has selected a date, which is a property of the tile class.
At the grid level, it changes its state based on its current state and the new information that it's observer receives from the tile. (In my calendar, the user can select a range of dates by choosing start date and end date, and can continue tapping tiles to change his date range selection.) This changes state at the grid level translates into a change in the start and/or the end date, so an NSDictionary property is updated.
At the calendar level, an observer sees the startDate/endDate dictionary change. Regardless of which grid this came from (there are two grids, and only one of them is active at a time. The tiles and the calendar do not need to be aware of this) the calendar's start and end dates are updated.
The calendar is a view that is planted into one of the other views of the application, initialized with a month to be shown, and with a selected date range (start and stop dates). Information is flowed down from the top though the pointers to each of the immediate subviews at any layer. Those subviews take care of keeping their subviews configured. I have eliminate the need to add explicitly add delegate methods or callbacks, and that has simplified the connections from top to bottom. Connections only go the the immediate level above or below in the hierarchy.
This may not seem like much after all, because it looks rather straightforward. But it wasn't clear until I spent awhile thinking about it. I hope it gives others some ideas for their own code. I would still like to know if there are other suggestions responding to my question.