¿Cómo se podría construir un software conectable?

Si tiene una aplicación de algún tipo y desea que sus usuarios puedan escribir complementos para ella, ¿cómo debe diseñarse la aplicación?

¿Qué debe tener en cuenta, qué patrones de diseño son para esto, etc.?

Depende un poco de su plataforma, pero algunas cosas generales a tener en cuenta

Versiones Lo que sucede si actualiza su aplicación, ¿todos los complementos antiguos se vuelven obsoletos (el problema de Firefox)

Aislamiento ¿Pueden los complementos hacer lo que quieran? ¿Siempre confías en ellos? ¿O necesita ejecutarlos en algún tipo de sandbox y solicitar permisos?

Actualizaciones ¿Cómo maneja las actualizaciones de complementos?

Seguridad ¿Cómo se asegura al autor de un complemento, evitar la suplantación de identidad o que se engañe al usuario para que instale código malicioso? Generalmente resuelto por algún tipo de firma de código

Serialización A menudo, cuando usa aislamiento de algún tipo, necesita serializar información entre diferentes hilos o procesos. ¿Cómo haces eso más eficientemente?

Extensibilidad ¿Qué aspectos necesita ampliar? ¿Cómo maximizar el potencial de los complementos sin que la API se vuelva difícil de manejar?

Si se dirige a desarrolladores de terceros para complementos, diría que lo más importante (desde mi experiencia) es ver la API y las clases de complementos como completamente diferentes del resto de la aplicación, y hacer que sea tan fácil de desarrollar para como sea posible. Es muy fácil para la arquitectura de la aplicación principal "desangrarse" en los complementos para que los autores de complementos tengan que aprender mucho más de lo que deben. Facilítelos, piense en qué tipo de interfaz y experiencia desearía como autor de complementos.

Otra buena mentalidad es no pensar como "El complemento hará todas estas cosas (en código) sino más bien," el complemento debe proporcionar esta información ". De esa manera, la aplicación puede consumir la información necesaria y hacer el procesamiento real que simplificará el complemento

También en general, cada vez que puede adoptar un enfoque descriptivo (metadatos, como xml) en lugar de código, tiene una gran ventaja, ya que los metadatos son más fáciles de transportar, versionar, implementar, proteger y pueden ser configurados más fácilmente por terceros.

Escribí este artículo de Code Project sobre el uso de MEF para la extensibilidad en .NET. Es una buena introducción.

Existen otros marcos de extensibilidad para .NET, como la arquitectura de complementos de SharpDevelop , Mono.Addins y System.AddIn .

Para Java, existe la arquitectura de complemento Eclipse .

El patrón general es este:

• Define un contrato (normalmente una interfaz) entre el host y la extensión
• Necesita un mecanismo de descubrimiento que se apague y busque extensiones instaladas
• Debe poder cargar dinámicamente las extensiones y hacer que el host las conozca

En la práctica, comparte mucho con la inyección de dependencia y el patrón de estrategia.

Solo necesita proporcionar una interfaz para los complementos.

Debe contener al menos un Activate-Methode (un punto de entrada), pero también querrás cosas como Initialize, etc.

Y debería existir la posibilidad de comunicarse con la aplicación host de forma similar a un registro, por ejemplo, para registrar elementos de menú. Por lo tanto, se deben proporcionar registros de cosas que se pueden cambiar / ampliar para complementos.

Además, debe haber algún almacenamiento accesible para los datos y objetos de la aplicación host, de modo que los complementos puedan llamar a sus rutinas. Esto se puede hacer fácilmente utilizando un contenedor DI como Unity y permitiendo que los complementos accedan a él, para que puedan resolver los servicios que necesitan.

Un Agregador de eventos es probablemente una buena idea también, por lo que los complementos pueden lanzar eventos y reaccionar a los eventos de otros complementos y la aplicación host de manera desacoplada. ¡Definitivamente quieres uno!