cocoa - clean - patrones de diseño ios

Patrones de diseño para los marcos de Cocoa de Apple: MVC, MVP, vista pasiva... ¿hacia dónde se dirige Apple? (6)

Para sentar las bases de esta pregunta, voy a decir que estoy obteniendo mis definiciones para MVC, MVP y Vista pasiva de lo siguiente:

Modelo View Controller (MVC)
Model View Presenter (MVP)
Vista pasiva (PV)

Apple siempre ha declarado que usa el patrón de diseño MVC, pero noté que en OS X 10.5 obtuvimos NSViewController, KVO, bindings, etc., objetos que parecen comportarse más como el patrón de diseño de Vista pasiva. ¿Es aquí donde Apple quiere que vayamos? Quiero planificar mi código de una manera que se desempeñe lo mejor posible con los patrones de diseño elegidos por Apple, por lo que quiero saber hacia dónde se dirige Apple. ¿Alguien tiene una pista?

No creo que Cocoa / OpenStep alguna vez haya seguido realmente a MVC como se describe en, por ejemplo, SmallTalk 80 . El Controlador SmallTalk es realmente algo que es responsable de interpretar la interacción del usuario con la Vista, que en el caso de Cocoa es manejada por NSControl y por lo tanto por la capa Vista (tal vez se descompone de esa manera dentro del marco, pero se supone que no echar un vistazo dentro; de eso se trata la abstracción :-). En relación con esos enlaces tuyos, la capa de Controlador en Cocoa realmente cae dentro del encabezado del presentador, particularmente cuando se consideran las distintas clases NS * Controller de Cocoa Bindings. Esos realmente son un transbordador entre una capa de vista y un modelo.

En mis propias aplicaciones, tiendo a tener cuatro capas distintas, incluso en lugares donde no están explícitamente separadas; la vista, el presentador, el servicio y el modelo. Entonces los "controladores del presentador" y los "controladores del servicio" tienen propósitos completamente separados; la lógica y los procesos están en los servicios, y los casos de flujo de trabajo y uso están en los controladores de vista. En términos de embalaje, si te gustan ese tipo de cosas, los servicios y el modelo juntos representan un resumen de "cosas que hacer en cosas" que pueden ser independientes del contexto. Los presentadores y las vistas representan el "y así es como un usuario de una aplicación Mac OS X desea usarlo", que depende del paquete inferior y encapsula comportamientos y clases específicas de AppKit (y específicas de AHIG).

No diría que Cocoa sigue el patrón de vista pasiva tal como se describe allí. Se dice que el controlador hace todo el trabajo para preparar la vista y enviar notificaciones de cambio. En Cocoa, un objeto de vista normalmente responderá a las notificaciones de KVO (a través de enlaces) desde el modelo, actualizará los datos del controlador al que está vinculado, lo preparará a través de formateadores de datos o transformadores de valores y finalmente lo mostrará en la pantalla.

Cocoa sigue MVC bastante bien, aunque por lo general el aspecto ''controlador'' se divide en controladores de vista y controladores de modelo. Puedes leer más sobre esto aquí . Si tiene algún ejemplo específico sobre dónde está confundido, tal vez pueda proporcionar más detalles sobre la forma en que Cocoa hace las cosas.

De la misma guía, esta sección explica algunos patrones de diseño adicionales que pueden serle útiles. En mi propia experiencia, aunque después de trabajar en algunos proyectos MVC en Cocoa tiende a ser bastante natural, no me preocuparía demasiado.

UH oh. MVC = el patrón más mal citado de la historia. He leído al menos 5 definiciones diferentes de esto.

Es posible que desee leer este artículo de Martin Fowler

Cualquier código de cualquier complejidad tiene muchos lugares donde pueden aplicarse diferentes patrones. MVC es prominente en los documentos de Cocoa porque explica las relaciones entre su código funcional (el modelo), su código de UI o diseño de IB (la vista) y los servicios de Cocoa que los unen (el controlador). Vale la pena enfatizarlo, particularmente en el dox introductorio, porque necesita una pequeña "llamada de atención" para dejar de pensar que tiene que escribirlo todo usted mismo, y empezar a pensar en cómo diseñar sus partes únicas, y confiar en el marco para hacer su trabajo. trabajo de plomería

Las definiciones variantes de MVC son legendarias, y vale la pena señalar que MVC no se describe en el libro canónico "Gang of Four", "Patrones de diseño". También vale la pena admitir que el modelo "MVC" de Cocoa no es el mismo que el SmallTalk 80 MVC (que es donde se originó la terminología).

Probablemente también valga la pena señalar que "GoF" realmente usa la palabra "patrón" para denotar un estilo particular de documentación, no la forma abstracta de diseñar el código que describe el patrón. Es una lástima que este uso se haya perdido en gran medida. Si todos entendiéramos la palabra de esa manera, podría decir "sería realmente útil si alguien escribiera un patrón para el MVC de Cocoa". ¡Entonces no estaríamos tan confundidos!

Los documentos de Apple realmente explican MVC mejor que cualquier otra cosa que leo. Básicamente, la confusión relacionada con MVC se debe a que es un patrón compuesto. Consiste en muchos patrones básicos. Aunque el MVC no fue discutido en Patrón de Diseño por la Banda de cuatro , los patrones básicos fueron.

La principal diferencia que creo es que en el mundo de Apple, el controlador es un patrón de mediación además de lo que normalmente es.
Por lo tanto, a diferencia de los modelos de enfoque tradicionales en el mundo de Apple, no notifica las vistas de cambio. No notifican a nadie de hecho. Si desea cambiar un modelo, debe hacerlo a través del controlador para asegurarse de que todos sean notificados de los cambios.

Creo que este enfoque es mucho mejor que el tradicional. No pone restricciones en los objetos modelo. No tienen que implementar ninguna interfaz específica. Solo tienen que resolver problemas específicos del dominio. Entonces puede reutilizarlos fácilmente en otras aplicaciones.

Son principalmente los objetos del controlador los que tienen que reescribirse en este enfoque. Por supuesto, Apple cambió eso con enlaces. Pero si no usa enlaces, entonces Controladores es específico de la aplicación.

Usando Apple MVC en C ++

De hecho, seguí el diseño de Apple al programar aplicaciones en C ++ utilizando Qt. Las vistas son QWidget. Puse todo el código que tiene que ver con la apariencia en una subclase QWidget. Luego configuro mi controlador como una subclase QObject y hago que cree los objetos de vista y conecte las señales de los QWidgets a las ranuras en mi QObject Controller. Mi clase de modelo es una clase regular que no hereda nada de Qt e implementa la lógica comercial. Se modifica por las ranuras de los controladores.

Alternativamente, los QWidgets se pueden crear fuera del controlador, por lo que puede reutilizar el controlador para otros tipos de vistas.

No estoy seguro si esto ayuda a alguien, pero creo que a veces es más fácil pensar en los patrones de Cacao en términos de C ++, porque estamos acostumbrados a obtener un patrón explicado en términos de un lenguaje estáticamente tipado como C ++ y Java.

Cocoa se basa en MVC (como Apple lo define ), y siempre ha estado en una tendencia de hacer cada vez más por usted. Así es como es actualmente.

Capa de visualización: NSView, NSWindow, NSCell, sus subclases y CALayer
Capa de controlador (desde 10.3): NSController y subclases (predominantemente NSArrayController)
Capa del modelo: Tradicionalmente, tenía que hacer esto completamente usted mismo, pero desde la versión 10.4, puede usar Core Data.

Los enlaces funcionan con KVO (y KVC), y son el pegamento que une las tres capas. Vincula las vistas a los controladores y los controladores al modelo.