En un buen principio de OOP, ¿debería un nodeView pedir que se agregue a un árbol, o un árbol debe agregar nodeView?

Question

Me pregunto qué es un buen principio programación orientada a objetos, si en una aplicación para iOS, hay una UITreeView, y una UINodeView, con el objeto de tener un UITreeViewrootNodeView y ramas de nodos de esta raíz fuera con leftChildNodeView y rightChildNodeView.

Si cada UINodeView objeto se puede "arrastrar y soltar" en cualquier lugar de la pantalla, que se implementa en UINodeView 's -touchesMoved controlador - que es buen principio programación orientada a objetos? Además, si un nuevo nodoView foo está realmente cerca de uno de los nodos que no tiene ningún elemento secundario izquierdo o derecho, el nodo foo se puede agregar a ese nodo como elemento secundario.

Y supongo que si otro nodeView que es bar y también tiene padres (es decir, también colgando), que tiene sentido que foo se puede añadir como niño bar 's también.

Si esto foo nodeView "pedir permiso a un nodo que se añaden como un hijo de la izquierda o hacia la derecha" y "añadir que si se permite", o de que las UIViewController o UITreeView detecta que un nodo se mueve dentro de sí mismo, y " decide que está cerca de otro nodo (de todos los nodos en la pantalla) y no tiene hijos izquierdo o derecho, y agrega foo como un niño "?

Obviamente, si solamente un nodo en el árbol puede añadir un nodo hijo, entonces el UITreeView puede hacer el trabajo, pero si cualquier nodo (colgando o no) puede ser un padre, entonces UIViewController o la vista principal UIView parece necesitar para hacer el trabajo.

¿Hacerlo de una manera u otra viola los buenos principios de OOP?

Answer 1

Diría que el UITreeView debe manejar esto y los nodos deben informarle a través de la comunicación de protocolo/delegado sobre los cambios de posición. El TreeView es el único objeto que puede verificar, si un cambio de posición de un nodo provoca colisión con otro nodo, etc.

Si desea escribir un código OOP realmente bueno, intente utilizar un "Modelo-Vista-Controlador" -pattern, donde su vista es su TreeView, su modelo debe contener todos los objetos de datos de nodo y proporcionar algunos métodos para la detección de colisiones entre los nodos, y su controlador debe recibir los cambios de posición de su vista, hablar con el modelo, decidir qué hacer y luego tomar las acciones apropiadas (como agregar un nodo como una hoja de otro nodo).

De esta manera, es completamente flexible para futuros cambios, como utilizar una base de datos en lugar de RAM para el almacenamiento de datos o usar el código para iPad en lugar de iPhone simplemente reemplazando la Vista.

Answer 2

Estoy de acuerdo con stk, es necesario que haya una clara distinción entre el modelo, que es la implementación de las reglas de negocio, y la vista (s), que son la representación visual.

El párrafo revelador es el último:

Obviamente, si solamente un nodo en el árbol puede añadir un nodo hijo, entonces el UITreeView puede hacer el trabajo, pero si cualquier nodo (colgando o no) puede ser un padre , luego UIViewController o la vista principal UIView parece necesitar hacer el trabajo.

En otras palabras, su modelo depende de las reglas comerciales.Necesita diseñar la lógica para que pueda expresar las reglas. Si tiene nodos flotantes libres, entonces claramente deben contener la lógica del archivo adjunto.

Por lo tanto, separe la lógica Árbol/Nodo de la lógica de Vista.