poo - que es modularidad java

¿Cómo modularizar una aplicación Java(grande)? (7)

Tengo una aplicación bastante grande (varias MLOC) a la mano que me gustaría dividir en partes separadas más fáciles de mantener. Actualmente, el producto está compuesto por unos 40 proyectos de Eclipse, muchos de ellos con interdependencias. Esto solo hace que un sistema de compilación continua sea inviable, ya que tendría que reconstruirse mucho con cada registro.

¿Hay una forma de "mejor práctica" de cómo

identificar partes que pueden ser separadas inmediatamente
Documentar interdependencias visualmente.
desenredar el código existente
manejamos los "parches" que debemos aplicar a las bibliotecas (actualmente se manejan colocándolos en el classpath antes de la biblioteca real)

Si hay herramientas (gratuitas / abiertas) para apoyar esto, apreciaría los punteros.

Aunque no tengo experiencia con Maven, parece que tiene un diseño muy modular. Ahora me pregunto si esto es algo que se puede modernizar de forma iterativa o si un proyecto que iba a usarse debería diseñarse teniendo en cuenta la modularidad desde el principio.

Editar 2009-07-10

Estamos en el proceso de dividir algunos módulos principales utilizando Apache Ant / Ivy . Una herramienta realmente útil y bien diseñada, que no te impone tanto como lo hace el experto.

Escribí algunos detalles más generales y una opinión personal sobre por qué lo estamos haciendo en mi blog, demasiado tiempo para publicar aquí y tal vez no sea interesante para todos, así que siga a su propia discreción: www.danielschneller.com

Lo primero que debe decidir es a qué infraestructura se moverá. Si se trata de una gran cantidad de módulos mantenidos de forma independiente (que se traducen en proyectos individuales de Eclipse) o lo considerará como una sola porción de código que se versiona y se implementa como un todo. El primero es adecuado para migrar a un entorno de construcción similar a Maven, mientras que el segundo contiene todo el código fuente a la vez.

En cualquier caso, necesitará un sistema de integración continua en ejecución. Su primera tarea es hacer que el código base se compile automáticamente, de modo que pueda dejar que su sistema de CI controle su repositorio de origen y lo reconstruya cuando cambie las cosas. Me decidí por un enfoque que no sea de Maven, y nos enfocamos en tener un entorno Eclipse fácil, así que creé un entorno de compilación utilizando archivos ant4eclipse y Team ProjectSet (que utilizamos de todos modos).

El siguiente paso sería deshacerse de las dependencias circulares: esto hará que su compilación sea más simple, deshacerse de las advertencias de Eclipse y, finalmente, le permitirá llegar a la etapa de "verificación, compilación una vez, ejecución". Esto puede tomar un tiempo :-( Cuando migres métodos y clases, no los MUEJES, sino que los extraes o los delegas y dejas su antiguo nombre por ahí y los dejas en desuso. Esto separará tu eliminación de calcomanías con tu refactorización, y permitirá el código " Fuera de "su proyecto para seguir trabajando con el código dentro de su proyecto.

Usted se beneficiará de un repositorio de origen que permite mover archivos y mantener el historial. CVS es muy débil en este sentido.

Maven es doloroso migrar a un sistema existente. Sin embargo, puede hacer frente a más de 100 proyectos de módulos sin mucha dificultad.

No es gratis, pero Structure101 le dará lo mejor que obtendrá en términos de soporte de herramientas para alcanzar todos sus puntos. Pero para el registro estoy sesgado, por lo que es posible que también desees revisar SonarJ y Lattix. ;-)

No recomendaría a Maven para una base de código fuente heredada. Podría darte muchos dolores de cabeza tratando de adaptar todo para trabajar con él.

Supongo que lo que necesitas es hacer un diseño arquitectónico de tu proyecto. Una herramienta podría ayudar, pero la parte más importante es organizar una vista lógica de los módulos.

Primero: buena suerte y buen café. Necesitarás ambos.

Una vez tuve un problema similar. Código heredado con terribles dependencias circulares, incluso entre clases de diferentes paquetes como org.example.pkg1.A depende de org.example.pk2.B y viceversa.

Comencé con maven2 y proyectos de eclipse fresco. Primero intenté identificar las funcionalidades más comunes (capa de registro, interfaces comunes, servicios comunes) y creé proyectos de maven. Cada vez que estaba satisfecho con una parte, implementaba la biblioteca en el repositorio central de nexus para que estuviera casi inmediatamente disponible para otros proyectos.

Así que poco a poco trabajé a través de las capas. maven2 manejó las dependencias y el complemento m2eclipse proporcionó una vista de dependencia útil. Por cierto, normalmente no es demasiado difícil convertir un proyecto de eclipse en un proyecto experto. m2eclipse puede hacerlo por usted y solo tiene que crear algunas carpetas nuevas (como src / main / java) y ajustar la ruta de compilación para las carpetas de origen. Solo toma un minuto o dos. Pero espere más dificultades, si su proyecto es un complemento de eclipse o una aplicación rcp y desea que Maven no solo administre artefactos sino que también genere e implemente la aplicación.

En opinión, eclipse, maven y nexus (o cualquier otro administrador de repositorio maven) son una buena base para comenzar. Tienes suerte, si tienes una buena documentación de la arquitectura del sistema y esta arquitectura está realmente implementada;)

Tuve una experiencia similar en una pequeña base de código (40 kloc). No hay reglas":

compilado con y sin un "módulo" para ver su uso
Comencé desde "módulos hoja", módulos sin otras dependencias.
Manejé dependencias cíclicas (esta es una tarea muy propensa a errores)
con maven existe una gran cantidad de documentación (informes) que se puede implementar en su proceso de CI
Con Maven siempre puede ver qué utiliza lo que hay tanto en el sitio como en NetBeans (con un
muy buen grafo dirigido)
Con Maven puede importar el código de la biblioteca en su base de código, aplicar parches de origen y compilar con sus productos (a veces esto es muy fácil, a veces es muy difícil)

Compruebe también el Analizador de Dependencia:
_{(fuente: javalobby.org )}

Netbeans:

_{(fuente: zimmer428.net )}

Usar OSGi podría ser una buena opción para ti. Permitiría crear módulos fuera de la aplicación. También puedes organizar dependencias de una mejor manera. Si define sus interfaces entre los diferentes módulos correctamente, entonces puede usar la integración continua ya que solo tiene que reconstruir el módulo que afectó en el registro.

Los mecanismos proporcionados por OSGi te ayudarán a desenredar el código existente. Debido a la forma en que funciona la carga de clases, también le ayuda a manejar los parches de una manera más fácil.

Algunos conceptos de OSGi que parecen ser una buena combinación para ti, como se muestra en wikipedia:

El marco se divide conceptualmente en las siguientes áreas:

Paquetes: los paquetes son componentes de tarro normales con encabezados de manifiesto adicionales.
Servicios: la capa de servicios conecta los paquetes de una manera dinámica al ofrecer un modelo de búsqueda-búsqueda-vinculación para objetos Java antiguos y sencillos (POJO).
Registro de servicios: la API para servicios de administración (ServiceRegistration, ServiceTracker y ServiceReference).
Ciclo de vida: la API para la administración del ciclo de vida (instalar, iniciar, detener, actualizar y desinstalar paquetes).
Módulos: la capa que define la encapsulación y la declaración de dependencias (cómo un paquete puede importar y exportar código).
Seguridad: la capa que maneja los aspectos de seguridad al limitar la funcionalidad del paquete a capacidades predefinidas.