Coesão e Baixo Acoplamento

Já pensou se outro tipo, que não seja Funcionario, precisar percorrer e retirar frutas da Cesta ? Você precisará reimplementar essa funcionalidade nas outras classes, ou então, você sempre precisará de um Funcionario para manipular a Cesta, ou seja, você terá alto acoplamento entre Funcionario e Cesta.

Mas um cesta, seguindo a OO não se automanipula. Quem faz essa manipulação observando a realidade não seria um agente externo? Pensei em criar uma classe cozinheiro.

De fato, ela não se manipula, mas deve oferecer um contrato, uma interface para ser manipulada. Quem quiser adicionar/remover frutas da cesta deve fazê-lo diretamente na cesta, e não deve precisar de um intermediário.

Na classe cesta, você colocará as operações que são possíveis se fazer numa cesta. No caso, adicionar e remover itens, saber quantos itens tem lá dentro, etc. Lembre-se sempre que classes, de maneira geral, são passivas. Ou seja, a cesta não se manipulará sozinha.

É a classe Funcionário, que em algum momento, irá chamar os métodos da cesta (enviar mensagem) para que ela coloque algum item que ela queira lá dentro.

Se na classe funcionário você colocar os métodos para controlar o conteúdo de uma cesta, você estará diminuindo a coesão da classe - já que agora ela tem mais uma responsabilidade - além de aumentando drasticamente seu acoplamento com a classe Cesta - uma vez que não haverá a possibilidade de usar uma cesta sem criar um Funcionário junto.

De fato, uma classe manipular estruturas de dados de uma classe terceira (como funcionário manipulando coisas da cesta) mais do que dela mesma num método é inclusive um mau cheiro de código documentado, conhecido como inveja dos dados. E a solução desse mau cheiro é justamente mover o método para a classe sendo manipulada.

Além disso, a modelagem de objetos é sempre uma abstração do mundo real. Muitas vezes você terá classes até para conceitos abstratos, como funções. Coisas que sequer representam objetos físicos de fato. A orientação a objetos também não consegue representar perfeitamente o mundo real. Por exemplo, ela é péssima para representar entidades metamórficas - que se transformam ao longo do seu ciclo de vida, ganhando e perdendo novos atributos e métodos. Por exemplo, como você modelaria a classe de um sapo, que começa a vida como um girino? Provavelmente teria que criar uma classe pouco coesa, com o método dos dois e controlar o estagio da vida através de estados.

Grato Vini, entendi sua explicação, Agora partindo para a prática, ficaria assim:

public class Cozinheiro 
{   	        
    public Object criarSaladas(Cesta cesta)
    {
	Collection<Fruta> listaDeFrutas  = cesta.getListaDeFrutas();
	for (Fruta fruta : listaDeFrutas) {
	        cortarFruta(fruta);
		adicionarFruta(fruta);
	}
	return "";//so para exemplo sei que nao faz sentido retornar isso
    }
    private void cortarFruta(Fruta f)
    {
       System.out.println("Cortei a Fruta!"+f.getNome());
    }
    private void adicionarFruta(Fruta f)
    {
        System.out.println("adicionei a Fruta:"+ f.getNome());
    }
}