Uno de los principios principales de MVC es vistas nunca propios datos. Este principio se repite muchas veces en WWDC Session 116. Pero entonces ¿por qué UIImageView (una vista) posee UIImage (un modelo)? ¿No viola el principio anterior?¿Por qué UIImageView posee UIImage? ¿Viola los principios de MVC?
¿O no entiendo nada aquí? ¿Tal vez solo porque UIImageView tiene una propiedad image no significa que posee ese UIImage?
La palabra propia se usa a menudo solo para indicar que un objeto ha retenido a otro. Obviamente, una vista que muestra una imagen debe retener esa imagen todo el tiempo que la necesite. Pero esta noción de "propiedad" es muy limitada, y no significa que la vista deba ser responsable de almacenar, cambiar o administrar la imagen.
Buena pregunta. En mi opinión, el UIImageView no "posee" el UIImage, pero obviamente necesita tener una referencia al mismo. UIImageView no crea una instancia de la imagen.
Se podría hacer el mismo argumento para una UILabel (una vista) que tiene una propiedad de texto (un modelo).
¿Por qué necesita tener una referencia a un UIImage? Normalmente habrá un controlador de pie entre la vista y el modelo. Cuando el modelo cambie, notificará al controlador, luego el controlador le dirá a la vista que vuelva a procesar. Pero aquí, UIImageView se vuelve a renderizar automáticamente cuando se cambia su propiedad de imagen. Sí, realmente suena estúpido cuando tienes que separar un UILabel y su propiedad de texto, pero este no es el ideal MVC predica, ¿no? –
En un modelo MVC puro, el controlador será "propietario" y contendrá referencias tanto a la vista como al modelo. La vista tendrá una referencia al modelo y sabrá cómo mostrarse. El controlador sigue siendo responsable de indicarle a la vista qué instancia de modelo usar. – picciano
De acuerdo. Pero la vista no necesita un modelo en su lista de ivar (o lista de propiedades). Simplemente puede tener un método como '- (void) renderWithModel: (Modelo *) m;' - que el controlador llamará cuando se modifique el modelo ¿correcto? Entiendo totalmente si UIKit hace que UIImageView tenga una propiedad de imagen por razones de rendimiento (por qué necesita un controlador para algo tan trivial), pero luego de alguna manera viola el MVC ideal que tengo en mente. –
Técnicamente, un UIImageView no posee una imagen, guarda una referencia a la copia de la imagen para poder representarla de manera eficiente. UIImage simplemente resulta ser inmutable, por lo que una copia es la misma instancia que el original.
UILabel se comporta de forma idéntica, pero declara explícitamente su propiedad text como copy.
Gracias por traer el punto mutable/inmutable :) –
Significa que UIImageView nunca debe cambiar directamente el UIImage, dejando ese trabajo a un UIController ¿verdad? Tiene sentido, gracias =) –
¿Pero por qué UIImageView necesita retener la imagen? Solo necesita esa imagen en el momento en que se dibuja en la pantalla, ¿verdad? –
UIImageView necesita una referencia a la imagen porque puede necesitar volver a dibujarse, y los datos que necesita para hacer eso es la imagen. Si no conserva la imagen, entonces la imagen podría desasignarse fácilmente en cualquier momento, y la vista quedaría con un puntero no válido (y probablemente se bloquee). Conserva la imagen que está usando hasta que alguien le dice que use alguna otra imagen. – Caleb