我想知道什么是优秀的OOP原则，如果在iOS应用中有UITreeView和UINodeView，UITreeView对象有rootNodeView ，此根节点以leftChildNodeView和rightChildNodeView分支。
如果可以“拖放”每个UINodeView对象，那么在UINodeView的{{1}}处理程序中实现的屏幕中的任何位置都是优秀的OOP原则？此外，如果新的nodeView -touchesMoved非常靠近没有左子节点或右子节点的节点之一，则节点foo可以作为子节点添加到该节点。
我想如果另一个nodeView是foo并且没有父母（也就是悬空），那么bar可以添加为foo的孩子是有意义的同样。
此bar nodeView“是否要求将节点的权限添加为左或右子项”和“如果允许则添加”，或foo或UIViewController检测到一个节点在自身内部移动，并“确定它接近另一个节点（屏幕上的所有节点）并且没有左或右子节点，并将UITreeView添加为小孩”？
显然，如果树中只有一个节点可以添加子节点，那么foo可以完成这项工作，但是如果任何节点（悬空与否）可以是父节点，那么UITreeView或主视图UIViewController似乎需要完成这项工作。
以某种方式这样做是否违反了良好的OOP原则？
答案 0 :(得分：1)
我说UITreeView应该处理这个问题，节点应该通过协议/委托 - 通知他通知位置变化。如果节点的位置变化导致与另一个节点的冲突等，TreeView是唯一可以检查的对象。
如果您想编写真正优秀的OOP代码，请尝试使用“模型 - 视图 - 控制器” - 模式，其中您的View是TreeView，您的模型应该包含所有节点数据对象并提供一些碰撞方法节点之间的检测，你的Controller应该从你的视图接收位置变化，与模型交谈，决定做什么然后采取适当的行动（比如将节点添加为另一个节点的叶子）。
通过这种方式，您可以完全灵活地应对未来的变化，例如使用数据库代替RAM进行数据存储，或者仅使用替换视图就可以使用iPad代替iPhone代码。
答案 1 :(得分：0)
我同意stk，需要明确区分模型（即业务规则的实现）和视图（视图表示）。
揭示段落是最后一段：
显然，如果树中只有一个节点可以添加一个子节点，那么 UITreeView可以完成这项工作，但是如果任何节点（悬空或不悬空）都可以 父，然后UIViewController或主视图UIView似乎需要 做好这份工作。
换句话说，您的模型取决于业务规则。您需要设计逻辑，以便表达规则。如果您有自由浮动节点，那么显然它们必须保持附件逻辑。
将Tree / Node逻辑与View逻辑分开。