java - ¿Cómo hacer código modular?
module osgi (10)
Como usted dice, la modularidad no es una cosa binaria, por lo que depende de su definición relativa.
Yo diría: ¿Puede usar un método dado en cualquier programa en el que necesite realizar esa función? ¿Es la "caja negra" donde no necesitarías saber qué hacía debajo del capó? Si la respuesta es no, es decir, el método solo funcionaría correctamente en ese programa, entonces no es verdaderamente modular.
Tengo algunos programas Java, ahora quiero saber si es modular o no, si es modular, hasta qué punto, porque la modularidad nunca puede ser un término binario, es decir, 0 o 1. ¿Cómo decido que un código en particular es modular? hasta este punto ¿Quiero saber cómo hacer el código mucho más modular?
Dado que se ha etiquetado con ''osgi'', puedo lanzar una perspectiva relacionada con OSGi.
La respuesta corta es que es posible pasar del código de espagueti completamente al modular en pequeños pasos; No tiene que ser una gran explosión. Por ejemplo, incluso el código de espagueti depende de algún tipo de biblioteca de registro de bolognaise, por lo que en cierto sentido, ya es modular, solo con One Very Big Metball (perdón, módulo).
El truco es romper la gran bola de carne en una porción más pequeña y luego una bola de carne ligeramente menos grande y luego repetir. Tampoco hay que hacer todo de una vez; simplemente corta un poco más cada vez hasta que no quede nada para eliminar.
En cuanto a OSGi, todavía es posible poner un uber-jar en un paquete. De hecho, puedes hacer esto sin cambiar los bits; ya sea modificando el Manifest.MF en su lugar, o envolviéndolo en otro JAR y especificando Bundle-ClassPath: metaball.jar en el manifiesto.
Si esto falla, las herramientas como BND pueden ayudar a generar los datos correctos que necesitaría, y luego se pueden colocar en un tiempo de ejecución OSGi con la suficiente facilidad. Pero ten cuidado con el código excesivamente acoplado y las cosas que se atascan con los cargadores de clases: te harán tropezar.
Hej
Consulte "Cómo encapsular software (Parte 1)" aquí:
http://www.edmundkirwan.com/encap/overview/paper7.html
Saludos,
Ed.
La idea package-by-feature ayuda a hacer que el código sea más modular.
Muchos ejemplos vistos en la web dividen las aplicaciones primero en capas, no en características
- modelos
- acceso a los datos
- interfaz de usuario
Sin embargo, parece mejor dividir las aplicaciones utilizando paquetes de nivel superior que se alinean con las características, no con las capas .
Aquí hay un example de una aplicación web que usa paquete por función. Anote los nombres de los paquetes de nivel superior, que se leen como una lista de características reales en la aplicación. Tenga en cuenta también cómo cada paquete contiene todos los elementos relacionados con una característica: los elementos no se distribuyen por todo el lugar; la mayoría de las veces, todos están en un solo paquete / directorio.
Por lo general, la eliminación de una función en dicha aplicación se puede implementar en una sola operación: la eliminación de un solo directorio.
La modularidad es relativa a quien está desarrollando el código. Pero creo que el consenso general es que el código modular es un código que tiene partes que pueden intercambiarse fácilmente sin cambiar la mayoría del código original.
En mi humilde opinión, si tiene 3 módulos AB y C y desea cambiar o reemplazar el módulo C por completo, si es una tarea SENCILLA, entonces tiene un código modular.
Los puntos clave son
- Separación de intereses
- Cohesión
- Encapsulación (se comunica a través de la interfaz)
- Sustituibilidad
- Reusabilidad
Un buen ejemplo de este tipo de sistema de módulos son las piezas de automóvil estándar, como los frenos de disco y el estéreo del automóvil. No quieres construir el estéreo del auto desde cero cuando estás construyendo autos. Prefieres comprarlo y enchufarlo. Tampoco quieres que el sistema de frenos afecte al estéreo del automóvil, o, en el peor de los casos, al sistema estéreo del automóvil.
Para responder a su pregunta, "¿Cómo decido que un código en particular es modular hasta este punto?", Podemos formular preguntas para probar la modularidad. ¿Puede sustituir fácilmente sus módulos con otra cosa sin afectar otras partes de su aplicación?
Los analizadores XML podrían ser otro ejemplo. Una vez que obtiene la interfaz DOM, realmente no le importa qué implementación de analizador XML se usa debajo (por ejemplo, Apache Xerces o JAXP).
En Java, otra pregunta puede ser: ¿Se puede acceder a todas las funciones a través de las interface ? La interfaz cuida bastante del acoplamiento bajo.
Además, ¿puedes describir cada módulo en tu sistema con una oración? Por ejemplo, un estéreo de coche reproduce música y radio. Los frenos de disco desaceleran el vehículo de forma segura.
( Esto es lo que escribí en ¿Qué es el desarrollo impulsado por componentes? )
Según Wikipedia, el desarrollo basado en componentes es un alias para la ingeniería de software basada en componentes (CBSE) .
[Es] una rama de la ingeniería de software, cuya prioridad es la separación de inquietudes con respecto a la amplia funcionalidad disponible en todo un sistema de software determinado.
Esto es algo vago, así que veamos más detalles.
Un componente individual es un paquete de software, o un módulo, que encapsula un conjunto de funciones relacionadas (o datos).
Todos los procesos del sistema se colocan en componentes separados, de modo que todos los datos y funciones dentro de cada componente están relacionados semánticamente (al igual que con el contenido de las clases). Debido a este principio, a menudo se dice que los componentes son modulares y cohesivos .
Entonces, de acuerdo con esta definición, un componente puede ser cualquier cosa siempre y cuando haga una cosa realmente bien y solo una cosa.
Con respecto a la coordinación de todo el sistema, los componentes se comunican entre sí a través de interfaces . [...] Este principio da como resultado componentes referidos como encapsulados .
Así que esto suena cada vez más como debería ser una buena API o SOA.
Las interfaces proporcionadas están representadas por una paleta y las interfaces requeridas están representadas por un símbolo de zócalo abierto unido al borde exterior del componente en UML.
Otro atributo importante de los componentes es que son sustituibles , por lo que un componente podría ser reemplazado por otro (en tiempo de diseño o en tiempo de ejecución), si el componente sucesor cumple los requisitos del componente inicial (expresados a través de las interfaces).
La reutilización es una característica importante de un componente de software de alta calidad. Un componente de software debe diseñarse e implementarse para que pueda reutilizarse en muchos programas diferentes.
Sustitución y reutilización es lo que hace que un componente sea un componente. Entonces, ¿cuál es la diferencia entre esto y la programación orientada a objetos?
La idea en la programación orientada a objetos (OOP) es que el software debe escribirse de acuerdo con un modelo mental de los objetos reales o imaginarios que representa. [...]
La ingeniería de software basada en componentes, por el contrario, no hace tales suposiciones y, en cambio, establece que el software debe desarrollarse pegando los componentes prefabricados como en el campo de la electrónica o la mecánica.
Para responder a su pregunta específica sobre cómo hacer que el código sea más modular, un par de enfoques son:
Una de las mejores herramientas para la modularización es detectar la reutilización del código. Si encuentra que su código hace exactamente lo mismo (o muy similar) en más de una vez, es un buen candidato para modularización.
Determine qué elementos de la lógica se pueden hacer independientes, en el sentido de que otra lógica los usaría sin necesidad de saber cómo se construyen. Esto es algo similar a lo que hace en el diseño de OO, aunque el módulo / componente no necesariamente tiene que corresponder a un objeto modelado como en OO.
Puede utilizar una herramienta de análisis de código como CAP para analizar las dependencias entre tipos y paquetes. Lo ayudarán a encontrar y eliminar cualquier dependencia cíclica, que a menudo es un problema cuando se trata de desarrollar un código modular. Si no hay dependencias cíclicas, puede comenzar a separar su código en frascos discretos.
En general, es una buena práctica codificar las interfaces si puede, esto generalmente significa que su código puede ser refactorizado y / o utilizado más fácilmente en diferentes contextos.
Los marcos de inyección de dependencia como Spring también pueden ayudar con la modularidad de su diseño. Como los tipos se inyectan con sus dependencias por algún proceso de configuración externo, no necesitan una dependencia directa en una implementación.
Suponiendo que entiendo su pregunta, que quiere saber qué es lo que hace que el código sea modular, ya que los módulos de código obviamente necesitarán cierta dependencia entre ellos para funcionar. Esta es mi respuesta:
Si puede dividir su sistema en módulos y puede probarlos de forma aislada, es una buena indicación de que un sistema es modular.
Algunos puntos de referencia para la modularidad:
- ¿Cuántas veces estás reescribiendo un código similar para realizar una tarea en particular?
- ¿Cuánto código tiene para refactorizar su código en caso de que cambie algo en alguna parte de su programa?
- ¿Son los archivos más pequeños y más fáciles de navegar?
- ¿Los módulos de la aplicación funcionan de manera adecuada e independiente cuando es necesario?
- ¿Cuán menos desastroso es tu código? ¿Se pierde todo el infierno cuando borras solo una función o variable? ¿Recibes errores impares al renombrar una clase? (Para Instancia, puede implementar un mecanismo de apilamiento para realizar un seguimiento de todos los saltos en su aplicación)
- ¿Qué tan cerca está el código del uso del lenguaje natural (es decir, los módulos y sus subcomponentes representan más objetos del mundo real sin preocuparse por el tamaño del archivo de origen de red)?
Para más ideas, mira esto y este sobre la calidad del software.
En cuanto a su preocupación de hacer que su código sea más modular, primero debe hacerse las preguntas anteriores, obtener respuestas específicas para ellos y luego echar un vistazo a this
La filosofía básica es dividir su aplicación en los fragmentos de código más pequeños posibles organizados de forma ordenada en una multitud de diseños de directorios fácilmente comprensibles y accesibles.
Cada método en su aplicación no debe hacer más que los cuantos mínimos de procesamiento necesarios . La combinación de estos métodos en más y más métodos de nivel macro te llevará de regreso a tu aplicación