Seja coeso e desligue-se um pouco :)

Hoje irei falar um pouco sobre coesão e baixo acoplamento. 
Primeiramente, o que significam esses termos?

1) Coesão: no Português claro, coesão significa que todo um contexto deve ter algum tipo de relação, uma harmonia. Se estivermos fazendo uma frase de um determinado assunto por exemplo, esta frase deve conter somente elementos pertinentes à aquele assunto, e não uma bagunça de outras coisas. No mundo da Informática, isso não é muito diferente. Devemos ter nossas estruturas coesas para evitar a complexidade dos nossos códigos. Vamos ver um exemplo na prática:

public class Impressora {
   public void imprimir() {
      conectarBancoDeDados();
      Documento documento = Documento.getDocumentosNaFila();

      System.out.println("Imprimindo documentos pendentes...");
      //Faz a comunicação com hardware para enviar os documentos para a impressora configurada. 
   } 

   public void conectarBancoDeDados() {
      Class.forName("oracle.sql.Driver");
      Connection conn = DriverManager.getConnection(urlBanco, usuario, senha); 
      PreparedStatement pstmt = conn.prepareStatement("select * from usuario");
      
      ResultSet rs = pstmt.executeQuery();
      //faz outras coisas complexas aqui  
   }
} 

Bom, ao ler esse código, claramente percebemos que a classe Impressora cuida de muitas coisas que ela não deveria cuidar, como podemos ver no método "conectarBancoDeDados". Analisando essa lógica, será mesmo que uma impressora deveria se conectar com um banco de dados? É aí que entra a coesão! Esta classe não está coesa, pois está executando tarefas além de sua responsabilidade. Devemos ter nossas estruturas fazerem o que é da alçada de cada um. Uma solução para esse exemplo seria mais ou menos desta forma:

public class Impressora {
   public void imprimir(Documento documento) {
      System.out.println("Imprimindo documentos pendentes...");
      //Faz a comunicação com hardware para enviar os documentos para a impressora configurada. 
   }
} 

Veja que retiramos a conexão com o banco na classe impressora, e que o documento que irá ser impresso já vem certo no método imprimir. Agora sim temos uma classe coesa, que faz somente o que foi projetada para fazer.

O papo está muito bom, mas e quanto ao baixo acoplamento? Nada como um exemplo prático:

public class Impressora {
   public void imprimir(Documento documento) {
      int numeroDePaginas = documento.numeroDePaginas;
      List<Autor> autores = new ArrayList<Autor>();
      for (Autor a : documento.autores) {        
         autores.add(a);  
      }
      System.out.println("Imprimindo documentos pendentes...");
      //Faz a comunicação com hardware para enviar os documentos para a impressora configurada. 
   }
}

Veja como conhecemos profundamente a classe Documento. E isso não é bom. Sabemos detalhes sobre esta classe, ou seja, a classe Impressora e Documento estão fortemente acopladas, consegue perceber?
Este tipo de coisa deve ser evitado, pois compromete toda uma estrutura. Imagine que alguém, em um belo dia, decide por algum motivo mudar a estrutura de armazenamento dos autores do documento, onde ao invés de List, irá armazenar numa estrutura Set. Nosso código do método imprimir() já estaria furado, pois teríamos que adequá-lo à nova estrutura, abrindo brechas para erros que antes não aconteciam. Encapsule o máximo de coisas que você puder, assim evitará grandes dores de cabeça!

Não sabe o que é encapsulamento? Então aguarde a próxima postagem, onde terei o maior prazer em tentar explicar.

Até logo.