objective c - ¿Qué describe mejor el objetivo-C y los enlaces de cacao?
objective-c cocoa (2)
Tengo problemas para entender los enlaces de cacao. ¿Alguien puede explicarme de qué se trata todo esto, de una manera que sea humanamente perceptible?
Bindings es un sistema para conectar sus vistas a sus controladores sin escribir mucho código de pegamento para hacer que se hablen explícitamente entre sí. Todo lo que tiene que hacer es configurar las propiedades en ambas clases * y conectar el enlace en IB.
El enfoque tradicional es que la vista tiene una o más salidas para hablar con el controlador (la mayoría de los ejemplos genéricos son delegate y target ) y la controladora tiene salidas para hablar con las vistas. Cuando el controlador actualiza el modelo, envía (por ejemplo) [view modelChange:newModelObject] . Cuando la vista desea actualizar el modelo, envía un mensaje de delegado a su delegado (el controlador), como el cambio de textDidChange: de textDidChange:
Con los enlaces, todo lo que tiene que hacer en el código es implementar las propiedades en la vista y las propiedades en el controlador, luego exponer una o más propiedades de la vista como enlaces *. Entonces solo hay que enganchar el enlace. Si es una clase de cacao, este es un pastel: simplemente configúralo en IB. Si es una clase personalizada propia, probablemente escribirá el bind:toObject:withKeyPath:options: message (no mucho más difícil).
Permítame reiterar que: con enlaces, su código de pegamento completo (la mayoría de las veces) es [view bind:@"viewProperty" toObject:self withKeyPath:@"controllerProperty.modelProperty" options:options]; en el controlador. Todo lo demás es manejado por los sistemas Bindings y KVO detrás de escena, y por los accesores de sus propiedades.
La desventaja es que debe cumplir estrictamente con los requisitos de Cocoa Bindings. Estas son simples, pero muchas de las aplicaciones más antiguas están diseñadas de una manera que no se ajusta a los Encuadernaciones de Cocoa.
- Debe crear objetos de modelo reales, no solo pasar objetos primitivos (por ejemplo, matrices de diccionarios). Si está usando Core Data, esto es fácil: sus objetos administrados son objetos modelo.
- Debe escribir sus accesores correctamente o sintetizar los accesores correctos. Por ejemplo, una propiedad NSString siempre debe ser
@property(copy), nunca@property(retain)(porque de lo contrario, se encontrará reteniendo la cadena mutable de otra persona, que luego mutarán mientras la sostiene). - Solo debe cambiar las propiedades de los objetos de su modelo por sus propiedades (
model.foo = bar) o por mensajes de acceso ([model setFoo:bar]), nunca por el acceso directo a la variable de la instancia. (Excepción obvia para los métodos de acceso en sí mismos, si ha escrito el suyo propio, porque deben acceder a la variable de instancia directamente).
Hay dos ventajas:
- Puede escribir una nueva clase de vista sin tener que rasgar una gran cantidad de código de pegamento. Lo más que tendrá que eliminar es algunos mensajes
bind::::para las propiedades de la vista anterior. Si, un par de años más tarde, decide que su vista actual simplemente no puede escalar a las capacidades futuras de su aplicación, esto le da la flexibilidad de eliminarlo y comenzar de nuevo con el mínimo dolor. - Más importante aún, cuanto menos código tenga que leer, más fácil será leerlo.
* Y, según la documentación, implementar un método de observación KVO en la clase de vista, pero en realidad nunca tuve que hacer esto. Presenté un error de documentación .
Añadido el 07/03/2009: Ah, encontré una cita. "Las subclases NSView pueden exponer propiedades adicionales que cumplen con la clave-valor-codificación / clave-valor-observación como enlaces al llamar al método de clase exposeBinding: para cada una de las propiedades". - NSKeyValueBindingCreation Por lo tanto, no debería necesitar implementar un método de observación KVO.
La respuesta anterior es muy comperhensiva y buena. Pensé que agregaría una respuesta que explique su núcleo sin involucrar específicamente a Cocoa o Objective-C. Esto se debe a que el concepto en sí es independiente del lenguaje, aunque los lenguajes dinámicos como Objective-C lo hacen mucho más fácil que el lenguaje más estático como C ++.
Ejemplo
Digamos que tienes dos objetos M y V. M tiene métodos:
setX(int x);
setY(int y);
int getX();
int getY();
Mientras que V tiene métodos:
setA(int x);
setB(int y);
int getA();
int getB();
Una forma de ver esto es que M tiene propiedades x e y e V tiene propiedades ay b . Desea que un cambio de propiedad x provoque un cambio en la propiedad b y un cambio en y provoque un cambio en a .
Por cambio en la propiedad x queremos decir, por ejemplo:
M.setX(10)
donde anteriormente
M.getX() != 10
Así que queremos una llamada de setX en M para hacer que una llamada a setA en V.
Lo que los enlaces le permiten decir es que la propiedad b en el objeto V está vinculada a la propiedad x en el objeto M. Y luego esta actualización se maneja automáticamente. Usted como programador no tiene que escribir código que verifique si x ha cambiado y luego llamar a setB en V. Bindings se encarga de esto automáticamente
Resumen
Los enlaces le permiten unir dos propiedades que existen en dos objetos diferentes, de modo que cambiar el valor de una de las propiedades hace que la propiedad dependiente en el otro objeto cambie al mismo valor.