plataforma node.js (node.js não é linguagem, ok?), fiquei empolgado com a idéia de poder fazer um scriptizinho.js (é ótimo ouvir isso de um gerente, não?) no lado back da força. Os primeiros exemplos de implementação sobre a plataforma não se preocupavam com a qualidade do código sugeridas pelos Jedis (Uncle Bob, Martin Fowler, Kent Beck, Booch, Gangue de Quatro* e etc.). Confesso que isso me deixava desanimado e me questionei se eu deveria investir o meu tempo neste novo mundo. Acertei! Hoje a coisa toda evoluiu e podemos afirmar que Javascript não é bagunça (ou talvez nunca tenha sido).
Quero escrever sobre um assunto que gosto muito: SOLID. Começo pela letra O do acrônimo por acreditar ser o de mais fácil implementação, inclusive em códigos existentes. Em linhas gerais o que Bertrand Meyer diz sobre o princípio do “aberto-fechado” é o seguinte:
“Uma classe só deve ser modificada quando erros forem encontrados. A classe pode ser estendida, mas nunca modificada.”
É difícil entender o valor do “aberto-fechado”. Talvez seja necessário escrever muitos códigos ruins para enxergar o real benefício deste princípio mas admito, minha vida ficou muito melhor depois que eu passei a escrever código limpo.
Acredito que exemplos de códigos sobre projetos factíveis são mais fáceis de entender e por isso, vamos imaginar o seguinte produto.
“Nós do grupo Eike Zords queremos construir uma solução inovadora para o setor logístico. Esse produto deverá ser capaz de retornar o menor custo de frete a partir de algumas variáveis: origem, destino e peso da mercadoria. Segundo nosso CEO, este produto já vale 1 bilhão de reais. “
O código acima apresenta diversos problemas mas quero comentar as deficiências sobre a ótica do “open-closed principle”.
Evolução dolorosa: A classe sempre será alterada quando funcionalidades forem adicionadas no produto. É o tipo de código que em pouco tempo ninguém mais quer colocar a mão. Legibilidade: As linhas acima são difíceis de ler, será complicado criar uma linguagem ubíqua com o dono do produto. “Véio, põe gordura pra mexer nessa bagaça” será a única técnica de estimativa adequada para tarefas que envolvam mexer no código acima.
Vamos melhorar a situação desse código? Começar pelos testes é uma técnica poderosa para se encontrar bons designs de objetos.
Para manter o foco sobre o assunto “open-closed” não vou copiar os códigos de testes que fiz. Eles realmente me ajudaram a evoluir o modelo.
Decidi criar uma especialização para cada tipo de frete. Deixo a responsabilidade de aceitar (ou não) fazer o cálculo do frete para algum especialista no assunto.
A distância não é importante para os “Correios” pois eles entregam em qualquer lugar do mundo! teoricamente.
Chegou o momento de colocar gerência na coisa toda. Vamos implementar um cara que seja responsável por dividir o trabalho entre todos os fornecedores de frete.
Pronto? Será que a “FornecedorFrete” não está com muita responsabilidade? Concordam que a forma de calcular o frete presente no método “calculaValorFrete” será alterada? Eu acredito que sim! Porém, quero fazer essa melhoria no momento que conversarmos sobre “Single responsibility principle” ou “cada macaco no seu galho”.
Uma vez me disseram que é importante devolver ao mundo parte do que o mundo te deu e por isso resolvi compartilhar meu conhecimento sobre desenvolvimento de software.