Tengo algunos programas de 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 ese particular? el código es modular hasta este punto. Quiero saber cómo hacer código mucho más modular?¿Cómo hacer código modular?
Suponiendo que entiendo su pregunta, quiere saber qué es lo que hace que el código sea modular, ya que obviamente los módulos de código necesitarán alguna dependencia entre ellos para funcionar. Esta es mi respuesta:
Si puede dividir su sistema en módulos, y puede probar esos módulos de forma aislada, eso es una buena indicación de que un sistema es modular.
Como dices, la modularidad no es algo binario, por lo que depende de tu definición relativa.
Yo diría: ¿Se puede utilizar un método determinado en cualquier programa donde 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.
La modularidad es relativa a quién 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 parte del código original.
En mi humilde opinión, si tiene 3 módulos A B y C y desea cambiar o reemplazar completamente el módulo C, si es una tarea SIMPLE hacerlo, entonces tiene un código modular.
Puede usar 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 dependencias cíclicas, que a menudo son un problema al tratar de desarrollar código modular. Si no hay dependencias cíclicas, puede comenzar a separar su código en tarros discretos.
En general, es una buena práctica codificar las interfaces si puede, esto generalmente significa que su código puede ser más fácilmente refactorizado y/o utilizado en diferentes contextos.
Los marcos de inyección de dependencias como Spring también pueden ayudar con la modularidad de su diseño. A medida que los tipos se inyectan con sus dependencias mediante algún proceso de configuración externo, no necesitan una dependencia directa en una implementación.
algunos puntos de referencia para la modularidad:
Para más ideas check this out y éste en software quality
Como por su preocupación en hacer su código más modular primero que debe hacerse las preguntas anteriores, obtener respuestas específicas para ellos y luego echar un vistazo en this
La filosofía básica es romper su aplicación en fragmentos un código lo más pequeño posible dispuestos ordenadamente a través de una multitud de distribución de directorios fácilmente comprensible y accesible.
Cada método en su aplicación no debe hacer más que el mínimo de procesamiento necesario. La combinación de estos métodos en métodos de nivel cada vez más macro que debe conducir de nuevo a su aplicación
Otro punto de referencia podría ser el "criterio de eliminación": si elimina X (paquete, clase, método, campo) de su programa, ¿qué se rompe? Si hay interrupciones, ¿qué tan "lejos" están del elemento eliminado? Si los elementos rotos son distantes, entonces eso significa que X era menos modular. –
(Anadir al comentario anterior) - Cuando elimina algo, inmediatamente expone sus conexiones con el resto del programa, todos los lugares donde está conectado al código de llamada. Más modularidad * generalmente * significa menos puntos de conexión, y generalmente significa que los puntos de conexión son más "locales" en alcance (por ejemplo, dentro de un solo paquete). –
+1! ¡absolutamente correcto! – OrangeRind
puntos clave son
Un buen ejemplo de dicho sistema de módulos son las piezas estándar del automóvil, como los frenos de disco y el estéreo del automóvil. No desea construir un estéreo de automóvil desde cero cuando está construyendo automóviles. Prefiere comprarlo y enchufarlo. Tampoco desea que el sistema de frenado afecte el estéreo del automóvil, o que el peor estéreo del automóvil afecte al sistema de frenos.
Para responder a su pregunta, "¿Cómo puedo decidir si un código en particular es modular hasta el extremo?", Podemos formular preguntas para probar la modularidad. ¿Puede sustituir fácilmente sus módulos por otra cosa sin afectar otras partes de su aplicación?
Los analizadores XML podrían ser otro ejemplo. Una vez que obtenga la interfaz DOM, realmente no le importa qué implementación del analizador XML se utiliza debajo (por ejemplo, Apache Xerces o JAXP).
En Java, otra pregunta puede ser: ¿Se puede acceder a todas las funciones a través de interface s? La interfaz prácticamente se encarga del bajo acoplamiento.
Además, ¿puede describir cada módulo de su sistema con una frase? Por ejemplo, un estéreo de automóvil reproduce música y radio. Los frenos de disco desaceleran el vehículo de forma segura.
(Esto es lo que escribí a What is component driven development?)
Según Wikipedia, el desarrollo basado en componentes es un alias para Component-based software engineering (CBSE).
[IT] es una rama de software ingeniería, la prioridad de los cuales es la separación de las preocupaciones respecto de la amplia funcionalidad disponible en todo un sistema de software dado.
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 relacionados funciones (o datos).
Todo sistema de procesos se colocan en componentes separados de manera que todos los datos y funciones dentro de cada componente son semánticamente relacionada (al igual que con el contenido de clases). Debido a este principio, a menudo se dice que los componentes son modular y cohesivo.
De acuerdo con esta definición, un componente puede ser cualquier cosa siempre que haga una cosa realmente bien y solo una cosa.
Con respecto a todo el sistema coordinación, componentes se comunican entre sí a través de interfaces . [...] Este principio da como resultado componentes a los que se hace referencia como encapsulado.
Esto suena cada vez más como lo que pensamos que debería ser una buena API o SOA.
El proporcionan interfaces están representados por una piruleta y requieren interfaces están representados por un símbolo socket abierto unido al borde exterior del componente en UML.
Otro atributo importante de componentes es que son sustituibles, de modo que un componente podría ser sustituido por otro (en tiempo de diseño o en tiempo de ejecución), si el los requisitos del componente inicial (expresado a través de las interfaces) se cumplen por el componente sucesor.
La reutilización es una característica importante de un componente de software de alta calidad . Se debe diseñar un componente de software y implementado para que pueda ser reutilizado en muchos programas diferentes.
La capacidad de sustitución y reutilización es lo que hace que un componente sea un componente. ¿Cuál es la diferencia entre esto y la Programación Orientada a Objetos?
La idea en programación orientada a objetos (POO) es que el software debe escribirse de acuerdo con un modelo mental de los reales o imaginarios objetos que representa. [...]
la ingeniería de software basado en componentes, por el contrario, no hace tales supuestos, y en su lugar afirma que el software debe desarrollarse mediante pegado componentes prefabricados juntos de manera mucho como en el campo de la electrónica o mecánica.
Para responder a su pregunta específica de cómo hacer el código más modular, un par de enfoques son:
Uno de mejor herramienta para la modularización se Spotting la reutilización de código. Si encuentra que su código hace la misma cosa exacta (o muy similar) en más de una ocasión, es un buen candidato para modularizar.
Determine qué partes de la lógica se pueden independizar, en el sentido de que otra lógica las usaría sin necesidad de saber cómo se construyen. Esto es algo similar a lo que debe hacer en el diseño OO, aunque el módulo/componente no necesariamente tiene que corresponderse con un objeto modelado como en OO.
La idea de package-by-feature ayuda a que el código sea más modular.
Muchos ejemplos vistos en las aplicaciones dividir web en primer lugar en las capas, no cuenta con
Parece mejor, sin embargo, para dividir las aplicaciones utilizando paquetes de nivel superior que se alinean con las características , no las capas.
Aquí hay una example de una aplicación web que usa paquete por característica. Tenga en cuenta 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 artículos relacionados con una característica: los artículos no se extienden por todos lados; la mayoría de las veces, están todos en un único paquete/directorio.
Normalmente, la eliminación de una función en una aplicación de este tipo se puede implementar en una sola operación: eliminación de un único directorio.
Dado que esto ha sido etiquetado con 'osgi', puedo arrojar una perspectiva relacionada con OSGi.
La respuesta corta es que es posible pasar del código completamente de espagueti al modular en pequeños pasos; no tiene por qué ser un gran estallido. Por ejemplo, incluso el código de espagueti depende de algún tipo de biblioteca de registro de boloñesa, por lo que, en cierto sentido, ya es modular, con One Very Big Metball (lo siento, módulo).
El truco es romper la gran albóndiga en un trozo más pequeño y luego una albóndiga un poco menos grande y luego recurse. No todo tiene que hacerse de una sola vez; simplemente salga un poco más cada vez hasta que no quede nada por 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 Manifest.MF en su lugar, o envolviéndolo en otro JAR y especificando Bundle-ClassPath: metaball.jar en el manifiesto.
En su defecto, las herramientas como BND pueden ayudar a generar los datos correctos que necesitaría, y luego se pueden eliminar fácilmente en un tiempo de ejecución OSGi. Pero ten cuidado con el código excesivamente acoplado, y las cosas que rebusca con los cargadores de clases: eso te hará tropezar.
Hej,
Sede, "Cómo encapsular el software (Parte 1)," aquí:
http://www.edmundkirwan.com/encap/overview/paper7.html
Saludos,
Ed.
Si el código es verdaderamente modular, cada componente debe ser una caja negra. Cuantos menos conocimientos conocen los componentes entre sí, más modular es el sistema. – Kevin