Cualquier persona usando Qi4J

Question

que estaba leyendo un artículo InfoQ el compuesto Programación Orientada a principios de:

http://www.infoq.com/articles/Composite-Programming-Qi4j

yo estaba interesado en saber si alguien está usando actualmente (o ha usado) el marco Qi4j en absoluto?

¿Cómo se compara con el uso de un marco de inyección de dependencia tradicional como Spring para el cableado de clases en conjunto. ¿Es más fácil tratar el gráfico de objetos resultante (basado en mixins en lugar de clases) desde el punto de vista del mantenimiento?

Answer 1

Bueno, llevo un año usando Qi4j en un proyecto. Una vez que se acostumbre al poder de mixins en su modelo de dominio, se estará preguntando cómo se las arregló sin ellos antes. De hecho, creo que el método POJO para crear modelos de dominio debería estar obsoleto. Crea código sistémicamente inmanejable. Debido a que el modelo mixin/composite es la característica importante de Qi4j, en lugar de DI, realmente no hay ninguna comparación en la plataforma Java.

En cuanto a las preocupaciones de Bozho: cuando se trata de declarar mixinas hay dos casos separados. En las entidades, es decir, el modelo de dominio, una interfaz típicamente solo tendrá una implementación, y de hecho querría evitar activamente varias implementaciones por razones de mantenimiento y de legibilidad. Entonces declaro la implementación directamente en la interfaz. Pero, solo es un valor predeterminado, que puede ser anulado por el compuesto si lo desea. Hasta ahora nunca he encontrado la necesidad de hacerlo.

El otro caso es servicios, que es bastante diferente. En muchos casos, habrá una sola implementación, por lo que volver a declarar la implementación en la interfaz está bastante bien. Sin embargo, hay muchos más casos con servicios en los que desea implementaciones diferentes, por lo que en esos casos simplemente declara el mixin en la declaración de tipo compuesto concreto. Entonces ambos estilos son posibles y recomendados por varias razones.

En cuanto a la fundición, ser capaz de lanzar un objeto es una ventaja, no es un problema. Si no tiene un casting de un rol a otro, tendrá que ser muy inventivo para evitarlo, lo que probablemente no simplificará su código.

Answer 2

Después de leer la primera parte del artículo enlazado, no me gustan dos cosas:

• las implementaciones se definen en la interfaz (utilizando @Mixins) - ¿y si estos deben ser burlaban, o implementaciones cambiaron ?
• requiere fundición

Al no tener experiencia con Qi4J, no puedo decir cómo esto resulta en la práctica, pero no se siente bien.

Answer 3

Esperemos que no sea demasiado tarde en esta discusión: Pero así es como lo veo.

Antes que nada, me gustan las ideas (Composites, Mixins, Ensambles) detrás de Qi4j, pero me retiene la complejidad de su uso.

Los conceptos deberían ser parte de un paraguas más amplio, como un lenguaje (como Java), que un marco, y deberían ser más fáciles de usar.

Me encontré con un problema hace 2 años que me dejó deseando tener algo así entonces.

Quería 3 comportamientos diferentes que podrían reutilizarse en un conjunto de granos. Algunos frijoles usaron todos ellos otros combinación de dos. No quería juntarlos a todos en una clase porque no tenía sentido. Por otro lado, estaba limitado por el hecho de que no podía tener herencia múltiple. La solución obvia: use una interfaz; lo que significa implementar lo que muchas veces. Recuerdo haberme quejado con un compañero de trabajo sobre el hecho de que espero tener una forma de proporcionar una implementación predeterminada para una interfaz. Esto para mí es un concepto OO simple que permite reutilizar comportamientos de una manera más limpia. Y si es el caso donde necesita algo diferente a la implementación predeterminada que implementar esa. Eso tendría más sentido y no frenaría ninguna ley natural que yo pueda ver.

Para responder a su pregunta, creo que los conceptos de este Qi4j le permiten pensar OO de manera más limpia, donde Spring es más estructural y no es comparable conceptualmente. Podrías pensar en la inyección de dependencia y no estar pensando en la primavera y estar pensando Qi4j y no estar pensando en la inyección del departamento.

Answer 4

Cuando leo el Qi4j en 2 minutos, 10 minutos, etc. tutoriales (el último es incompleto), la única pregunta obvia que me vino a la mente fue ¿cómo puedo integrar esto con las entidades gestionadas JPA/Hibernate? Me gustaría ver una solución que se integre perfectamente con JPA. Sin JPA implica la adopción de Qi4j en mi opinión. Me encantaría ver un artículo del autor (es) que muestra la integración con JPA y Spring, dos cosas que tienen una profunda penetración en el mundo de Java Enterprise. Si la integración es sencilla, se producirá una adopción rápida.

Answer 5

Bozho; Para su pregunta acerca de Mixins declarado en interfaces,

Las implementaciones de Mixin pueden anularse, ya sea en interfaces "superiores" (es decir, sub), ya que el orden de búsqueda para implementaciones ocurre "por método" y va desde la interfaz declarada , de izquierda a derecha, y luego a cada una de las super interfaces (también de izquierda a derecha en la cláusula extends). O bien, puede anular en el Conjunto de un compuesto;

public void assemble(ModuleAssembly module) 
{ 
    module.entities(Account.class).withMixins(LdapAuthenticatorMixin.class); 
    : 
} 

donde el LdapAuthenticatorMixin puede ser abstracta y sólo anular un solo método.

Answer 6

Kabram; La integración con JPA se ha intentado más de una vez. Si tenemos dos tecnologías superpuestas pero no totalmente comparables, terminará solo con la intersección de posibilidades. Entonces, hay dos enfoques básicos para integrar Qi4j con JPA.

1. Para limitar las opciones de JPA, para que las estructuras de datos mucho más flexibles que necesita Qi4j puedan utilizarse completamente. Hacer eso no tiene sentido, ya que ir directamente a SQL es mucho más eficiente, y eso es lo que elegimos.

2. Para limitar el modelo de datos de Qi4j para que se ajuste a un modelo de datos JPA existente. Hacer esto eliminará la mayoría de las ventajas de por qué las personas eligen Qi4j en primer lugar. Por lo tanto, hemos decidido no gastar los ciclos para hacer esto. Sin embargo, creo que la extensibilidad de Qi4j es lo suficientemente buena para hacer tal integración sin hackear Core Runtime, y simplemente crear una EntityStore.