Artigo no estilo: Curso

Do que trata o artigo

Este artigo vai discutir a criação de programas que podem ser estendidos e mantidos mais facilmente, quer seja por você, por sua equipe ou por terceiros. Aproveitando o tema, falarei sobre programas que suportam plugins e darei um exemplo de mecanismo feito “como antigamente”, que servirá como ponto de partida para a apresentação do MEF (Managed Extensibility Framework).

Para que serve

A discussão sobre como criar programas mais fáceis de estender e manter é útil para qualquer profissional de desenvolvimento em qualquer plataforma. O MEF é um meio padronizado, conceitualmente menos sujeito a erros, que deve ser utilizado por quem precisa desenvolver softwares que sejam extensíveis através de plugins e não precisa se preocupar com os detalhes da infraestrutura necessária para isto.

Em que situação o tema é útil

Se você escreve programas, quaisquer que sejam eles, um dos seus principais objetivos deve ser criar programas fáceis de manter e estender. É nisto que o MEF ajuda. Simplifica a criação de plugins para aplicativos.

Resumo do DevMan

O MEF (Managed Extensibility Framework) é um novo recurso do .NET Framework 4 para criação de programas que podem ser estendidos dinamicamente (plugins no jargão de desenvolvimento de programas). Nesta primeira parte do artigo será abordada a criação de programas fáceis de manter e estender, segundo alguns conhecidos princípios de designs que serão úteis inclusive para o entendimento da arquitetura do MEF. Além disto, um mecanismo de plugins “old school” será criado para poder servir de comparação na parte 2 deste artigo, que mostrará uma implementação muito melhor feita com o auxílio do MEF.

Enquanto pensava sobre como falar do MEF, que é um framework para facilitar a criação de programas que suportam extensão por plugins, peguei-me analisando o quanto de design há neste framework propriamente dito e como a discussão sobre design tem perdido espaço para frameworks cada vez mais especializados e metodologias cada vez mais voltadas ao código. O que eu quero dizer é que a quantidade de material e discussão sobre design é relativamente pequena quando comparada a outros tipos de informações.

Nessa linha de pensamento, pensei o seguinte: criar programas que suportem plugins, com ou sem o MEF, é uma ótima maneira de se conversar sobre design. Pela própria natureza do problema somos levados a criar código menos acoplado, impelidos a programar para interface, ao invés de tipos concretos e quase naturalmente obrigados a encapsular aquilo que pode ser alterado.

Estes três princípios de design serão muito úteis para entendimento e utilização do MEF, mas são também princípios básicos para ajudar qualquer desenvolvedor a criar programas mais fáceis de manter e alterar, quer eles suportem plugins ou não.

Apenas para ilustrar o que estou dizendo, vou relatar um exemplo real. Durante uma manutenção em uma classe para impressão de notas fiscais me deparei com uma estrutura muito interessante que continha as seguintes classes:

· ModelFiscalNote: Classe principal do modelo para nota fiscal (havia outras abaixo dela, mas para este relato ela basta);

· ModelPrintDocument: Classe para definição de um documento a ser impresso. Contém propriedades para tamanho do formulário e contém também uma lista de elementos para impressão;

· ModelPrintElement: Classe para definição de um elemento de impressão. Contém propriedades para posicionamento (X, Y) e tipo de fonte (entre outras);

· ModelPrintDocumentAdapter: ...

Quer ler esse conteúdo completo? Tenha acesso completo