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.

[ Hits: 42.064 ]

Por: Edvaldo Silva de Almeida Júnior em 05/05/2008 | Blog: http://emeraldframework.net


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...

Página anterior     Próxima página

Páginas do artigo
   1. Introdução
   2. PE ou POO?
   3. Unidades básicas
   4. O princípio da caixa-preta
   5. Critério nº 01: Reusabilidade / FAN-IN
   6. Critério nº 02: Baixa complexidade / FAN-OUT
   7. Critério nº 03: Acoplamento
   8. Critério nº 04: Coesão
   9. Conclusão
Outros artigos deste autor

Programação (III) - Programação Orientada a Objetos (POO)

KDE em um PC "primitivo"

Software Livre... e um passo além

Como a Tecnologia pode ajudar a Democracia?

Software Livre e o Código de Defesa do Consumidor

Leitura recomendada

O "Synaptic"

Como o Google Earth pode induzir a reinstalação de uma distro Linux

Criando uma agenda com o Lazarus

Formatando exibição de datas no Linux

Instalação do navegador Vivaldi no GNU/Linux

  
Comentários
[1] Comentário enviado por bjaraujo em 05/05/2008 - 14:04h

parabéns, cara; acho que ainda tenho sequelas pela exposição ao BASIC. ahuahuaha

[2] Comentário enviado por stremer em 05/05/2008 - 19:03h

excelente. O dificil é mesmo conhecendo tudo isto conseguir implementar nos prazos malucos que os gerentes de TI e pessoal do marketing impõe (rs)

[3] Comentário enviado por rafastv em 05/05/2008 - 19:17h

De leitura agradável e rápida, parabéns!

[4] Comentário enviado por kabalido em 05/05/2008 - 21:53h

Parabéns cara! Continue assim, os seus artigos são muito bons.
Valeu!!

[5] Comentário enviado por EdDeAlmeida em 06/05/2008 - 08:51h

stremer,

Tem de fazer ouvido de mercador para os caras que ficam pressionando para acelerar o trabalho. Se você foge dos esquemas bem definidos, acaba perdendo mais tempo no final.

Abraço e oobrigado a todos!

[6] Comentário enviado por douglascrp em 06/05/2008 - 09:04h

excelente artigo... assim como o primeiro artigo, depois que se começa a ler, é impossível parar até terminar...

parabéns

[7] Comentário enviado por leowalker em 06/05/2008 - 15:18h

muito bom, estou esperando o proximo para dar continuidade...

Abraço e parabens.

[8] Comentário enviado por vodooo em 07/05/2008 - 09:57h

Cara, parabéns, realmente de leitura muito agradável!

Abraços

[9] Comentário enviado por EdDeAlmeida em 07/05/2008 - 19:12h

O próximo artigo já está no forno... deve estar pronto para ser postado no início da semana que vem. Aí é só esperar a fila andar. Mais uma vez obrigado pelos comentários e pelo apoio de todos.

[10] Comentário enviado por rl27 em 09/05/2008 - 11:14h

Parabéns pela série de artigos. Muito boa mesmo!

Estou ansioso pela continuação. Com certeza ainda darei minhas contribuições à comunidade.

Valeu!

[11] Comentário enviado por joaomc em 09/05/2008 - 13:53h

O princípio da caixa preta é bonito na teoria, mas na prática a coisa não é bem assim. Muitas vezes você *precisa* saber o que há por trás daquele método que está chamando, para, por exemplo, saber os efeitos colaterais, se o método é thread-safe, etc.

Mas estou só sendo chato, o artigo ficou bom, parabéns :)

[12] Comentário enviado por EdDeAlmeida em 09/05/2008 - 19:43h

joaomc,

Concordo em parte. Mas saber se um método é thread-safe não viola necessariamente o princípio da caixa-preta. O que viola é escrever código que dependa do algoritmo usado por essa ou aquela função. Isso é uma violação grave, que cria dependência. A questão de ser ou não thread-safe é mais relacionada com o conhecimento dos requisitos do módulo. Vamos discutir isso quando formos falar em análise de requisitos.


rl27,

Obrigado pelo comentário. E tenho certeza que em breve estarei também lendo seus artigos aqui. Basta estudar e estar com a mente aberta para aprender.


Ed

[13] Comentário enviado por marcio_paim em 14/02/2012 - 22:14h

Excelente série de artigos.


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner
Linux banner
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts