Comprender el patrón de layout de MVC en Cocoa Touch

Por lo general, simplemente armé una aplicación de forma aleatoria, siempre que funcione, pero esto significa que no prest atención a ningún patrón de layout. Actualmente, mi aplicación hace un amplio uso de las variables globales (llevo una instancia de mi AppDelegate en cada controller de vista para acceder a las properties que declaré en mi AppDelegate.h ). Aunque hace lo que quiero que haga, he leído que esta no es una buena práctica de layout.

Entonces quiero comenzar a hacer que mi código sea "legítimo". Sin embargo, no puedo imaginar mi aplicación en este momento sin variables globales. Son tan importantes para el bienestar de la aplicación, pero esto debe significar que estoy haciendo algo mal, ¿verdad? Simplemente no puedo imaginar cómo más haría algunas cosas. Tomemos por ejemplo esto:

introduzca la descripción de la imagen aquí

Tiene dos controlleres de vista aquí, un SideViewController y un MainViewController . Usando variables globales, como por ejemplo, si toda la aplicación tiene una instancia compartida de SideViewController y MainViewController ( appDelegate.sideViewController y appDelegate.mainViewController ), puedo comunicarme fácilmente entre los dos controlleres de vista, de modo que si presiono "News Feed" en mi SideViewController , puedo decirle a MainViewController que vuelva a cargar su vista.

No puedo imaginar, sin embargo, cómo se haría esto si no fueran variables globales? Si ocurre un evento en mi SideViewController , ¿cómo notificaré a mi MainViewController , de una manera que esté de acuerdo con los estándares de layout?

No puedo imaginar, sin embargo, cómo se haría esto si no fueran variables globales? Si ocurre un evento en mi SideViewController, ¿cómo notificaré a mi MainViewController, de una manera que esté de acuerdo con los estándares de layout?

De la misma manera que lo hace ahora, excepto que SideViewController hace reference al MainViewController desde un lugar diferente.

¿Cómo se crean estos dos controlleres de vista? Es probable que ocurra de una de estas dos maneras:

  1. Uno de los objects crea el otro. En este caso, tal vez MainViewController crea SideViewController.

  2. Algún otro object, como el delegado de la aplicación u otro controller de vista, los crea ambos.

En el primer caso, el MainViewController tiene una reference al SideViewController tan pronto como lo crea. Puede almacenar esa reference en una de sus propias variables de instancia, de modo que siempre pueda enviar posts al SideViewController que creó. De manera similar, el MainViewController puede darle al SideViewController una reference a sí mismo (es decir, al MainViewController), y el SideViewController puede almacenar eso y usarlo en el futuro para hablar con su MainViewController.

El segundo caso es similar: si el delegado de la aplicación (o algún otro object) crea MainViewController y SideViewController, ese object conoce ambos objects y puede configurar cada uno con una reference al otro.

En ambos casos, los objects en cuestión pueden comunicarse entre ellos con la misma facilidad con que lo hicieron y no hay necesidad de una variable global.

Lo que he explicado anteriormente es quizás la forma más simple de lograr lo que solicitó: la comunicación entre dos objects. Hay una serie de patrones que se pueden usar para refinar la relación entre esos objects para mejorar aún más su código:

  • delegación: otorgue a SideViewController una propiedad de delegado y defina algún protocolo que establezca lo que SideViewController espera de su delegado. Implemente ese protocolo en MainViewController. Haga que su instancia de MainViewController sea delegada de SideViewController. SideViewController no necesita saber exactamente qué tipo es su delegado, solo le importa que su delegado implemente el protocolo requerido. Esto hace que sea más fácil usar SideViewController con algo más que MainViewController si surge esa oportunidad, o para usarlo en un proyecto diferente.

  • notifications: SideViewController puede que ni siquiera necesite un delegado; simplemente puede transmitir notifications sobre ciertos events a cualquier object que esté escuchando. Esto es particularmente eficaz si es posible que más de un object necesite saber algo que sucede en SideViewController, o si los objects que se preocupan por las acciones de SideViewController puedan cambiar.

  • MVC: en lugar de decirle a MainViewController que algo ha cambiado, SideViewController solo cambia los datos en el model. Siempre que aparezca la vista del MainViewController (o la vista de cualquier otra vista del controller, en este caso), el controller lee los datos del model y se vuelve a visualizar.

Si está interesado, puede que desee get una copy de los patrones de layout de cocoa de Erik Buck, que explica estos patrones y muchos otros con gran detalle. No sientas que tienes que aprender todo de una vez, o que es demasiado problema. Aprenda un poco a la vez y vea cómo mejora (o no) sus proyectos.