Diseño de software basado en complementos

Soy un desarrollador de software que está dispuesto a mejorar sus habilidades de diseño de software. Creo que el software no solo debería funcionar, sino también tener un diseño sólido y elegante para ser reutilizable y extenso para propósitos posteriores.

Ahora estoy buscando ayuda para encontrar buenas prácticas para problemas específicos. En realidad, estoy tratando de descubrir cómo diseñar un software que sea extensible a través de complementos.

Las preguntas que tengo son las siguientes:

• ¿Deben los complementos poder acceder a la funcionalidad de los demás? Esto traería dependencias, supongo.
• ¿Qué debería ofrecer la aplicación principal a los complementos si quiero, por ejemplo, desarrollar un software multimedia que reproduzca videos y música, pero que luego pueda agregar funcionalidad a los complementos que digamos poder leer el estado del video ( tiempo, bps, ...) y mostrarlo. ¿Significaría esto que el reproductor en sí mismo debería ser parte del programa principal y ofrecer servicios a los complementos para obtener dicha información o habría una forma de desarrollar el reproductor como un complemento también pero ofrecer de alguna manera la posibilidad a otros complementos para interactuar con él?

Como puede ver, mis preguntas son principalmente para propósitos de aprendizaje mientras me esfuerzo por mejorar mis habilidades de desarrollo de software.

Espero encontrar ayuda aquí y disculparme si algo está mal con mi pregunta.

Casi cualquier software que "quiera" extenderse a lo largo del tiempo, por múltiples contribuyentes que no están estrechamente vinculados o coordinados, puede beneficiarse de una arquitectura de plug-in de algún tipo. Ejemplos comunes son sistemas operativos, herramientas CAD y GIS, herramientas de dibujo y manipulación de imágenes, editores de texto y procesadores de texto, IDEs, navegadores web, sistemas de gestión de contenido web y lenguaje y marcos de programación. Los complementos son la base de los sistemas extensibles.

Las arquitecturas de complementos suelen utilizar la escritura de pato . El arquitecto define un conjunto común de métodos (por ejemplo open, close, play, stop, seek, etc.), que cada plugin entonces implementos (ya sea totalmente o en parte). Algunos métodos son obligatorios, mientras que otros pueden ser opcionales o útiles solo en casos específicos.

Cuando el programa principal se ejecuta inicialmente, verifica ./pluginsla existencia de complementos en una o más "áreas de complementos" (como directorios conocidos ). Los encontrados se cargan en el programa.

A menudo, deben existir complementos en el momento en que se ejecuta el programa principal. El núcleo de Unix y el servidor web Apache suelen funcionar de esta manera; deben reiniciarse para "ver" y usar nuevos complementos. Sin embargo, los complementos pueden ser más dinámicos; aquí el programa principal verifica periódicamente los complementos recién agregados o modificados (por ejemplo, comparando una plugins-last-loadedmarca de tiempo almacenada con la marca de tiempo "última modificación" para un directorio de complementos). El programa principal luego (re) cargaría complementos, ya sea todos, en el caso simple / ingenuo, o solo los nuevos / modificados, si es más sofisticado.

A menudo existe un requisito de "registro", ya que cada complemento no solo es código, sino que también incluye algunos metadatos que comunican cómo se integra el complemento en el conjunto. Un complemento de reproductor de música, por ejemplo, podría ser necesario para indicar qué tipo (s) de archivos puede reproducir, qué arquitectura (s) de procesador puede ejecutar, qué recursos necesita (por ejemplo, cuánta memoria necesita ser asignada) y otros atributos necesarios para que el programa principal decida qué complemento usar para reproducir qué archivo.

Los mecanismos para el registro de complementos, la carga y la interacción con el programa principal son bastante específicos del lenguaje y el marco. Debido a que hay mucha "orquestación" en curso, con algunas funciones manejadas por el programa principal y otras por sus complementos (de los cuales podría haber bastantes), configurar un programa para la extensibilidad requiere cuidado y consideración, y una vista arquitectónica del programa como "un sistema" en lugar de "una sola pieza de código".

La mayoría de los proyectos a gran escala ya habrán elegido un marco de plugin, o diseñado uno propio. También hay una serie de marcos de plugins genéricos diseñados para simplificar la conversión de su programa en un sistema extensible.

(Respuesta a la pregunta 1) Si bien los complementos pueden usar la funcionalidad de los demás, normalmente lo harían a través de los métodos / API predefinidos que el arquitecto presentó. El uso de este tipo de "escritura de pato" ayuda a evitar la súper interdependencia, y significa que no está necesariamente claro si una característica determinada es proporcionada por un código "central" o un complemento. De hecho, habiendo adoptado una estrategia de complemento, muchos desarrolladores implementan incluso funciones "centrales" como complementos, solo los que se incluyen con el programa principal. Si bien tener enredos espaguetis de complementos no es ideal, no es raro ver algunos complementos que requieren la existencia de otros complementos.

(Respuesta a la pregunta 2) Como arquitecto, lo principal que ofrece complementos es una arquitectura, por ejemplo, un conjunto de métodos a través de los cuales se configuran, registran e invocan, y un diseño y conjunto de requisitos en los que los complementos operarán . El programa principal, mientras se ejecuta, generalmente expone muchas, si no todas, sus estructuras de datos internos y métodos a complementos. Esto es obviamente una exposición de seguridad. Se pueden usar varias técnicas de sandboxing (y se utilizan cada vez más), pero la mayoría de las veces, los complementos son códigos "confiables", que funcionan como si fueran parte del programa principal.

Para más lectura:

• Vale la pena estudiar la página de complementos de Wikipedia .
• Un buen tutorial sobre cómo hacer que un editor sea extensible utilizando el marco de plugin de Yapsy.
• Explicación de un sistema de plug-in básico para Python