¿Marco de inyección de dependencia para el Cacao? [cerrado]

Objection by AtomicObject. Se moldea en la imagen de Guice.

Me arriesgaré a hablar de esto. La inyección de dependencia como se describe en la respuesta superior no aborda el problema central que están teniendo aquellos que buscan usarla. Nos gustaría un medio de desarrollo donde el componente A no instancie directamente o haga referencia al componente B. El componente A está vinculado por el protocolo al componente B y no está referenciado en absoluto por el componente A. Esto permite que el componente B sea reemplazado en cualquier momento sin tocar el componente A. Voté por abajo, pero investigaré su referencias como parece que hay unos pocos que están de acuerdo con usted. No estoy tratando de debatir, sólo busco aprender. Me gustaría entender más sobre el enfoque de "no, no necesitas hacer eso".

Typhoon

Hace casi un año, publiqué: https://github.com/typhoon-framework/Typhoon

El Typhoon-website enumera las características clave. Un breve resumen:

• No invasivo. No se requieren macros o XML. Usa un potente enfoque de tiempo de ejecución de Objective-C.

• Facilita tener múltiples configuraciones de la misma clase base o protocolo.

• Sin cuerdas mágicas - soporta refactorización IDE, finalización de código y comprobación en tiempo de compilación.

• Admite la inyección de controladores de vista y la integración de storyboard.

• Admite tanto el inicializador como la inyección de propiedades, además de la administración del ciclo de vida.

• Potentes funciones de gestión de memoria. Proporciona objetos preconfigurados, sin la sobrecarga de memoria de singletons.

• Excelente soporte para dependencias circulares.

• Magra. Tiene un huella muy baja, por lo que es apropiado para dispositivos con limitaciones de CPU y memoria.

• Probado en batalla-utilizado en todo tipo de Appstore-aplicaciones destacadas

• Un equipo central distribuido internacionalmente (incluso supervisamos StackOverflow), por lo que el soporte para cualquiera de sus preguntas nunca está lejos :)

Documentos de API y aplicación de ejemplo

• API docs: http://www.typhoonframework.org/docs/latest/api /
• Tenemos una buena muestra app: https://github.com/jasperblues/Typhoon-example

Control de calidad:

También mantenemos un sólido sistema de control de calidad.

• Cada commit desencadena una serie de pruebas de regresión
• Mantenemos una alta cobertura de pruebas.

No es necesario crear instancias del objeto en el archivo NIB. Si establece el Propietario del archivo a la clase de su objeto y luego enlaza cosas en la vista/ventana/lo que sea hasta eso, puede establecer su objeto como propietario en tiempo de ejecución cargando el archivo nib manualmente. De esta manera, puede tener una instancia dinámica de un objeto que aún recibe dependencias inyectadas correctamente.

¿Qué pasa con la implementación de la inyección de dependecy en Objetivo-COI

¿Qué pasa con ObjectivePim? ObjectivePim

He escrito un contenedor DI muy simple, el código está en GitHub. Solo puede hacer lo básico, es decir. descubre las dependencias de un objeto y satisfacerlas usando otros objetos dados. He encontrado que para ser utilizable en aplicaciones del mundo real, el código es muy simple y es divertido hackear con.

¿Alguien ha visto la característica Referencias asociativas de Mac OS X 10.6?

Creo que con esto sería posible construir o ya tener algo similar a DI. Por lo que he visto sin embargo, cualquier referencia que se necesita en un objeto tiene que ser obtenida manualmente usando objc_getAssociatedObject().

Manfred

Interface Builder no hace NINGUNA inyección de dependencias. No es necesario. Interface Builder serializa objetos. Cuando un nib es "awoken "(también conocido como opened), no hay" dependencias " que resolver there solo hay propiedades que establecer. Muy, muy simple. La apertura de un plumín se basa únicamente en el protocolo NSCoding y la codificación clave-valor.

Inyección de dependencia, más o menos un proyecto de hacer-trabajo en el mejor de los casos, o en el mejor de los casos una capa de pegamento generalizada entre los componentes diseñados de forma independiente, es de ninguna utilidad en el código Objective-C bien escrito. Estás pidiendo una herramienta que no necesitas.

En Objective-C, el software que requiere un servicio anónimo declara un Protocolo. A continuación, los servicios adoptan este protocolo. Los clientes cargan servicios como complementos dinámicos. Por otro lado, si el servidor fue escrito antes que el cliente, se trata simplemente de escribir un nuevo plug-in que adapte la interfaz existente al protocolo. Esto es menos trabajo y más sencillo que tratar de definir un sistema intermedio basado en datos para "descubrir" (por favor) una interfaz en tiempo de ejecución.

¿No es obvio para todos que el gran secreto de DI es solo que es una forma de escribir código en XML en lugar de en el idioma nativo? Realmente me gustaría escuchar un buen argumento en cuanto a cómo XML es de alguna manera un mejor lenguaje de programación que un lenguaje de programación real. No tiene ningún sentido.

Trabajo con Spring todo el día y he comprobado Groovy. De ninguna manera soy un experto en XCODE/Cocoa, pero IB solo hace alguna inyección de dependencia, lo que Groovy ni siquiera afirma estar haciendo.

Creo que no está buscando DI, sino más bien un conjunto bien compilado de bibliotecas integradas que le ahorra escribir una gran cantidad de código que otras personas también han escrito. Creo que no hay frameworks como Spring para Cocoa porque por alguna razón la gente tiende a ver "Open Source" como " no plataforma dependiente " y por lo tanto Cacao es un poco dejado fuera en el frío.

Sin embargo, dependiendo de sus necesidades, hay algunas bibliotecas gratuitas de código abierto disponibles para Cocoa, todas listadas en CocoaDev en una nice list.

Sé que no es primavera, pero espero que ayude.

DI es una propiedad de un entorno de ejecución en tiempo de ejecución que requiere enlace dinámico. Soy muy nuevo en Obj-C y Cocoa así que puedo hablar fuera de turno. A menos que me falte algo, no veo cómo se podría implementar DI excepto interpretando Obj C en lugar de compilarlo, o modificando el entorno de tiempo de ejecución.

Sospecho que el comportamiento similar a DI de IB se debe a que hay un entorno de tiempo de ejecución específico de dominio asociado con aplicaciones que se construyen con él.

Estoy feliz de estar aunque corregido.

Las categorías parecen ser una implementación de mixin, permitiendo el envío dinámico de métodos a un delegado. Bastante genial y similar al concepto de interfaz de Java, pensé que los detalles difieren y de lo siguiente, no puedo ver si las constantes se pueden definir en una categoría, aunque los campos de miembros no pueden.

Objective-c categories