Programação (II) - Modularização
Continuando a série sobre programação, vamos falar sobre modularização. Como dividir adequadamente um sistema? Qual a unidade ideal? Como quebrar funções? Como saber se um módulo está realmente bom? Esse artigo vai tentar responder algumas dessas questões e dar argumentos para pensarmos em muitas outras.
Parte 7: Critério nº 03: Acoplamento
Imagine que você acabou de comprar um maravilhoso home theatre para seu apartamento. É um equipamento de alta tecnologia, com excelente qualidade de som e imagem, e você está imensamente satisfeito com a aquisição.
Só que quando você vai instalar o aparelho, percebe que há apenas uma entrada de eletricidade para atender todos os módulos do aparelho, e que essa entrada está situada numa das caixas de som, sendo que a eletricidade é distribuída de lá para os outros módulos.
Alguns meses depois de adquirido o aparelho, a referida caixa de som que distribui eletricidade para o home theatre queima. E aí você começa a ver que o esquema de passar toda a eletricidade por um único lugar é problemático, pois agora você simplesmente não pode ligar o seu equipamento apenas porque uma das caixas queimou.
Assim, vemos que a ligação desnecessária (elétrica) entre a caixa e os demais módulos é prejudicial. Uma caixa de som devia receber do equipamento apenas o sinal de som, e não devia enviar nada em retorno. Qualquer ligação adicional é desnecessária e prejudicial, comprometendo o funcionamento do sistema como um todo.
Esse é um exemplo de mau acoplamento.
A ligação ideal entre dois módulos de um sistema é a menor possível, ou seja, os módulos devem trocar apenas e tão somente as informações necessárias, nada mais. Isso concorda com o princípio da caixa-preta, que nós já vimos.
Tomemos um exemplo mais específico:
Imagine que um módulo necessita de outro que calcule o valor da soma dos itens de uma conta de restaurante. Então ele deve enviar para o outro apenas os números a serem somados, recebendo deste apenas o valor total. Isso seria o acoplamento ideal, conhecido como "acoplamento de dados".
Agora imagine que além dos números a serem somados, o módulo chamador passa também o número do CPF do cliente que vai pagar a conta.
Há aí vários riscos potenciais:
1) Perda de performance, já que o fluxo de informações entre os módulos implica em movimento dos registradores e manipulação de memória, coisas que consomem tempo;
2) Possibilidade de alteração da informação desnecessária, o que causaria erros mais adiante, muito difíceis de serem localizados;
3) Confusão de raciocínio, pois o módulo teria um desnecessário acréscimo da lógica, sem qualquer benefício adicional; e,
4) Dificuldade de manutenção, pois um programador de manutenção iria perder horas tentando entender a função do CPF dentro daquele contexto.
Assim, o acoplamento entre dois módulos deve ser apenas o mínimo necessário para o cumprimento da função de ambos. O que passar disso provém do maligno...
Só que quando você vai instalar o aparelho, percebe que há apenas uma entrada de eletricidade para atender todos os módulos do aparelho, e que essa entrada está situada numa das caixas de som, sendo que a eletricidade é distribuída de lá para os outros módulos.
Alguns meses depois de adquirido o aparelho, a referida caixa de som que distribui eletricidade para o home theatre queima. E aí você começa a ver que o esquema de passar toda a eletricidade por um único lugar é problemático, pois agora você simplesmente não pode ligar o seu equipamento apenas porque uma das caixas queimou.
Assim, vemos que a ligação desnecessária (elétrica) entre a caixa e os demais módulos é prejudicial. Uma caixa de som devia receber do equipamento apenas o sinal de som, e não devia enviar nada em retorno. Qualquer ligação adicional é desnecessária e prejudicial, comprometendo o funcionamento do sistema como um todo.
Esse é um exemplo de mau acoplamento.
A ligação ideal entre dois módulos de um sistema é a menor possível, ou seja, os módulos devem trocar apenas e tão somente as informações necessárias, nada mais. Isso concorda com o princípio da caixa-preta, que nós já vimos.
Tomemos um exemplo mais específico:
Imagine que um módulo necessita de outro que calcule o valor da soma dos itens de uma conta de restaurante. Então ele deve enviar para o outro apenas os números a serem somados, recebendo deste apenas o valor total. Isso seria o acoplamento ideal, conhecido como "acoplamento de dados".
Agora imagine que além dos números a serem somados, o módulo chamador passa também o número do CPF do cliente que vai pagar a conta.
Há aí vários riscos potenciais:
1) Perda de performance, já que o fluxo de informações entre os módulos implica em movimento dos registradores e manipulação de memória, coisas que consomem tempo;
2) Possibilidade de alteração da informação desnecessária, o que causaria erros mais adiante, muito difíceis de serem localizados;
3) Confusão de raciocínio, pois o módulo teria um desnecessário acréscimo da lógica, sem qualquer benefício adicional; e,
4) Dificuldade de manutenção, pois um programador de manutenção iria perder horas tentando entender a função do CPF dentro daquele contexto.
Assim, o acoplamento entre dois módulos deve ser apenas o mínimo necessário para o cumprimento da função de ambos. O que passar disso provém do maligno...