No seguimento de uma apresentação do GASP no Porto, dedicada a Padrões de Desenho, e de uma recomendação nesse sentido, comecei a ler um livro chamado “Holub on Patterns: Learning Design Patterns by Looking at Code”, de um autor chamado Allen Holub. Quem o recomendou disse que tinha lhe mudado a forma de ver a programação Orientada a Objectos. Antes do livro, li um artigo… polémico do mesmo autor, intitulado “Why extends is evil“, a defender a utilização de interfaces em detrimento da herança, e não utilização de herança de implementação e get/sets (se estiverem interessado no tema, recomendo também uma réplica: Why Extends is Not Evil). Recomendo vivamente este artigo, bem como os comentários sobre o mesmo. Já na leitura do livro, que é uma alternativa ao clássico “Design Patterns” do GoF, e que apesar de baseado em exemplos Java se lê e aplica a C# (obviamente), tenho encontrado algumas reflexões e comentários muito interessantes. Um destes, de que me recordei hoje ao ler o livro do João Hugo Miranda e José Almeida, “Desenvolvimento Orientado por Objectos- Domain-Driven Design, Testes Unitários e Refactoring“, diz o seguinte:
«The real abomination in MVC architecture is the “data-bound grid control,” a table-like widget that effectively encapsulates the SQL needed to fill its cells from a database. What happens when the underlying data dictionary changes? All this embedded SQL breaks. You’ll have to search out every screen in the system that has a data-bound control and change that screen using a visual tool. Going to a “three-tier” system, where the UI layer talks to a layer that encapsulates the SQL, which in turn talks to the database, does nothing but make the problem worse since the code you have to modify has been distributed into more places. In any event, if the middle tier is made of machine-generated code (usually the case), then it’s very existence is of little use from a maintenance point of view.
All this modifying-every-screen-by-hand business is way too much work for me. Any time savings you may have made in using some tool to produce the initial code is more than lost as soon as the code hits maintenance.»
Polémico talvez., mas o argumento faz todo o sentido.
O que me fez lembrar este excerto, por curiosidade, foi a defesa, no livro do João Hugo Miranda e José Almeida (página 67, “Módulos”), de que os módulos (assemblies) devem estar estruturados em torno de conceitos do domínio do problema, e não em torno de conceitos tipo camadas, como sejam Apresentação, Negócio e Acesso a Dados.
E isto, por sua vez :-), chamou-me a atenção porque, nos desenvolvimentos em BizTalk, a recomendação “oficial” e tida por boa prática é agrupar as coisas em assemblies por tipo de artefacto: um assembly para os schemas, outro para as orchestrations, outro para os pipelines, outro para os mapas, etc. O problema desta recomendação é óbvio: se mudarmos um schema utilizado num qualquer processo de negócio, vamos acabar a substituir uma assembly da qual dependem todos os outros componentes do projecto, e não apenas o processo que utiliza esse schema – em BizTalk, por causa das dependências, para substituir essa assembly teremos de desinstalar as assemblies que dela dependam. Parece-me que esta é uma recomendação tem de ser revista, e substituída por um agrupamento semântico (possivelmente por processo).
E finalmente, outro comentário que também tinha aqui para fazer, refere-se a convenções de codificação para BizTalk. Quase todas elas, e existem 3 ou 4 diferentes, defendem a utilização de prefixos nas próprias shapes das orquestrações. Ora se na generalidade das shapes só cabem 12 a 18 caracteres, usar prefixos como Send_ é um desperdício em termos de facilidade de leitura. Adicionalmente, os nomes que se usam nas shapes não são identificadores, mas apenas para conveniência “humana”. E o ícone que acompanha a shape já a identifica como send/receive/listen/etc., por isso… para quê o prefixo? Fica aqui o link, é para um post de um Leonid Ganeline.
jota
