Pular para o conteúdo

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.
Edvaldo Silva de Almeida Júnior EdDeAlmeida
Hits: 47.417 Categoria: Linux Subcategoria: Software
  • Indicar
  • Impressora
  • Denunciar
O Viva o Linux depende da receita de anúncios para se manter. Ative os cookies aqui para nos patrocinar.
Não conseguimos carregar os anúncios. Se usa bloqueador, considere liberar o Viva o Linux para nos patrocinar.

Parte 8: Critério nº 04: Coesão

Enquanto o acoplamento é relacionado com dois ou mais módulos, a coesão é um critério de um só módulo.

Um módulo é dito coeso quando ele realiza apenas uma tarefa.

Uma das melhores maneiras de avaliar a coesão de um módulo é observar o nome dele. Vejamos um exemplo:

CalculaSomaEImprime: Como se pode ver, esse módulo realiza duas tarefas. Para melhorar a coesão, seria bom dividí-lo em dois, sendo um para calcular a soma e outro para imprimir o resultado. Com isso tornaríamos as duas operações independentes e reduziríamos a complexidade. Um módulo como esse é pouco reutilizável (fan-in baixo), já que só pode ser usado por outro módulo que precise da soma seguida da impressão. Já os módulos CalculaSoma e ImprimeValorSoma, que resultariam da quebra dele, seriam melhor aproveitados.

O Viva o Linux depende da receita de anúncios para se manter. Ative os cookies aqui para nos patrocinar.
Não conseguimos carregar os anúncios. Se usa bloqueador, considere liberar o Viva o Linux para nos patrocinar.
O Viva o Linux depende da receita de anúncios para se manter. Ative os cookies aqui para nos patrocinar.
Não conseguimos carregar os anúncios. Se usa bloqueador, considere liberar o Viva o Linux para nos patrocinar.
   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

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

Programação (I) - Planejamento e Otimização

Como a Tecnologia pode ajudar a Democracia?

Instalando o Fedora Core 5 via NFS

Instalando o Dynebolic sem instalador

Gravando CDs em modo texto

Conhecendo e usando o gerenciador de pacotes pacman

Packer - Instalando pacotes do AUR no Arch Linux

Hamachi - Redes virtuais utilizando software e internet

Servidor Openfire integrado ao Active Directory (Nível de Floresta 2008 R2)

#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

Entre na sua conta para comentar.