Voltando ao assunto de acoplamento e coesão, queria falar de algo mais especifico. Algumas dicas pra evitar um sistema altamente acoplado e com baixa coesão. Uma forma simples de fazer seu sistema perder coesão é nas heranças e classes bases.

Agora você pergunta o que é uma classe base... se você se perguntou isso já ta no caminho certo. Uma classe base é uma da qual varias outras classes dependem. No sistema operacional, por exemplo, uma das classes mais básicas é o Kernel do sistema... sem ele nada funciona. E quando você vai desenvolver um sistema é muito importante você saber identificar o que é base e o que é especifico, porque a classe básica é aquela que você só deve mexer quando for realmente necessário. Se você tem uma classe que o sistema inteiro usa e você tem que mudar ela toda a semana algo foi feito errado, muito provável que ela esteja sem coesão.

Uma boa forma de pensar isso numa hierarquia de classes, você vão ter aquelas classes que sustentam o sistema... frameworks, bibliotecas, componentes, coisas que servem para todo mundo usar. Essas classes terão um acoplamento bem alto, varias outras precisarão delas. Acima delas as classes devem ir ficando cada vez mais especificas e quanto mais especificas elas se tornam menos acopladas elas devem ser. Você nunca deve ter uma classe especifica dependendo de outra classe especifica. Vamos pegar um exemplo concreto... um carro.

Vou pegar as classes "Roda", "Chassi", "Motor", "Banco", "Radio","Ar condicionado". "Chassi" é a classe mais básica desse carro, sem essa peça você não monta mais nada no carro, O "Motor" também seria uma classe básica, estando acima do "chassi" porque você precisa dele para montar o "Motor". "Banco", "Radio" e "Ar condicionado" são classes especificas, elas dependem da "Chassi" e "Motor" para funcionarem, mas elas não dependem de outras especificas para funcionar... Imagina se pra usar o "Radio" você tivesse que ligar o "Ar condicionado" ou que pra usar o banco do seu carro você tivesse que ter um "Radio". Não faz o menor sentido, né?! 

E nos sistemas de computador a logica não é muito diferente, existem outras maneiras de ver isso e exceções mas a ideia básica é sempre cada classe deve ter sua responsabilidade, seus atributos e deve ser identificado a importância dela no projeto todo. E o melhor é fazer isso antes de executar o projeto. Cria um organograma das classes, projetar a arquitetura do sistema antes de começar a desenvolver evita o desperdício de tempo e dinheiro com retrabalho ao descobrir que uma classe especifica foi usada como base, ou que as classes receberam atribuições erradas... tudo isso é mais fácil de revolver no papel quando é só um desenho do que num sistema pronto já sendo usado pelo cliente.

E é isso... um projeto bem planejado, com classes coesas e uma arquitetura clara e bem pensada evita muitos problemas e facilita muito a vida de todos os envolvidos. E eu sei que não é fácil fazer todo esse trabalho de planejamento e analise do problema, mas garanto pra vocês que é um trabalho que se paga rapidamente quando você precisar implementar novas funções ou dar manutenção nas que já existem e isso for realmente coisa de poucos minutos e não meses.