Design de software baseado em plug-in

Sou desenvolvedor de software que deseja melhorar suas habilidades de design de software. Acho que o software não deve funcionar apenas, mas também possui um design sólido e elegante para ser reutilizável e extensivo para fins posteriores.

Agora estou em busca de ajuda para descobrir boas práticas para problemas específicos. Na verdade, estou tentando descobrir como projetar um software que seria extensível via plug-ins.

As perguntas que tenho são as seguintes:

• Os plug-ins devem poder acessar a funcionalidade um do outro? Isso traria dependências, eu acho.
• O que o aplicativo principal deve oferecer aos plug-ins, se eu quiser, digamos, desenvolver um software multimídia que reproduza vídeos e músicas, mas que posteriormente poderá adicionar funcionalidades aos plug-ins que, digamos, serão capazes de ler o status do vídeo ( tempo, bps, ...) e exiba-o. Isso significa que o próprio player precisaria fazer parte do programa principal e oferecer serviços aos plug-ins para obter essas informações ou haveria uma maneira de desenvolver o player como um plug-in também, mas oferecer de alguma forma a possibilidade para outros plug-ins para interagir com ele?

Como você vê, minhas perguntas são principalmente para fins de aprendizado, pois eu me esforço para melhorar minhas habilidades de desenvolvimento de software.

Espero encontrar ajuda aqui e pedir desculpas se algo estiver errado com a minha pergunta.

Praticamente qualquer software que "queira" ser estendido ao longo do tempo, por vários colaboradores que não estão estreitamente vinculados ou coordenados, pode se beneficiar de uma arquitetura de plug-in de algum tipo. Exemplos comuns são sistemas operacionais, ferramentas CAD e GIS, ferramentas de desenho e manipulação de imagens, editores de texto e processadores de texto, IDEs, navegadores da web, sistemas de gerenciamento de conteúdo da web e linguagem e estruturas de programação. Plugins são a base de sistemas extensíveis.

As arquiteturas de plug-in normalmente usam digitação de pato . O arquitecto define um conjunto comum de métodos (por exemplo open, close, play, stop, seek, etc.), que cada um plug-in, em seguida, implementos (na totalidade ou em parte). Alguns métodos são obrigatórios, enquanto outros podem ser opcionais ou úteis apenas em casos específicos.

Quando o programa principal é executado inicialmente, ele verifica uma ou mais "áreas de plug-ins" (como ./pluginsdiretórios conhecidos ) quanto à existência de plug-ins. Os encontrados são carregados no programa.

Geralmente, os plug-ins devem existir no momento em que o programa principal é executado. O kernel do Unix e o servidor da web Apache normalmente funcionam dessa maneira; eles devem ser reiniciados para "ver" e usar novos plugins. No entanto, os plug-ins podem ser mais dinâmicos; aqui o programa principal verifica periodicamente os plug-ins adicionados ou alterados recentemente (por exemplo, comparando um plugins-last-loadedregistro de data e hora armazenado com o registro de data e hora "modificado pela última vez" para um diretório de plug-ins). O programa principal então (recarregaria) os plugins - todos eles, no caso simples / ingênuo, ou apenas os novos / alterados, se for mais sofisticado.

Geralmente, existe um requisito de "registro", com cada plug-in não apenas como código, mas também incluindo alguns metadados que comunicam como o plug-in se integra ao todo. Um plug-in do music player, por exemplo, pode ser necessário para indicar que tipo (s) de arquivos ele pode ser reproduzido, quais arquiteturas de processador podem ser executadas, quais recursos são necessários (por exemplo, quanta memória precisa ser alocada) e outros atributos necessários para o programa principal decidir qual plug-in usar para reproduzir qual arquivo.

Os mecanismos para registro, carregamento e interação de plugins com o programa principal são bastante específicos da linguagem e da estrutura. Como existem muitas "orquestrações" em andamento, com algumas funções manipuladas pelo programa principal e outras por seus plug-ins (das quais podem ser algumas), a configuração de um programa para extensibilidade requer cuidado e consideração, além de uma visão arquitetônica. do programa como "um sistema" em vez de "um único pedaço de código".

A maioria dos projetos de larga escala já escolheu uma estrutura de plug-in ou criou sua própria. Há também várias estruturas de plug-ins genéricas projetadas para simplificar a transformação do seu programa em um sistema extensível.

(Resposta à pergunta 1) Embora os plug-ins possam usar a funcionalidade um do outro, eles normalmente o fazem através dos métodos / APIs predefinidos que o arquiteto apresentou. O uso dessa "digitação de pato" ajuda a evitar a super interdependência e significa que não está necessariamente claro se um determinado recurso é fornecido pelo código "principal" ou por um plug-in. De fato, depois de adotar uma estratégia de plug-in, muitos desenvolvedores implementam até recursos "essenciais" como plug-ins - apenas aqueles fornecidos com o programa principal. Embora ter emaranhados de espaguete de plug-ins não seja o ideal, não é incomum ver alguns plug-ins que exigem a existência de outros plug-ins.

(Resposta à pergunta 2) Como arquiteto, a principal coisa que você oferece aos plug-ins é uma arquitetura - por exemplo, um conjunto de métodos pelos quais eles são configurados, registrados e chamados, e um design e conjunto de requisitos nos quais os plug-ins irão operar . O programa principal, durante a execução, geralmente expõe muitas, senão todas, suas estruturas e métodos de dados internos a plugins. Esta é obviamente uma exposição de segurança. Várias técnicas de sandboxing podem ser (e estão sendo cada vez mais) usadas, mas na maioria das vezes, os plug-ins são códigos "confiáveis", funcionando como se fossem parte do programa principal.

Para leitura adicional:

• Vale a pena estudar a página de plug-in da Wikipedia .
• Uma boa explicação de como você pode tornar um editor extensível usando a estrutura do plugin Yapsy.
• Explicação de um sistema de plug-in básico para Python