Essa é a segunda parte
desse post aqui.
Evite responsabilidades
Objetos devem ser preguiçosos ao extremo. Evite responsabilidades, se tiver que aceitá-las, mantenha-as vagas e delegue o trabalho de verdade para outros.
O efeito final é que cada método vai fazer um fragmento muito pequeno de trabalho. Segundo o próprio Alan Kay, em um sistema orientado a objetos bem feito, você não consegue saber onde o trabalho está sendo realmente feito, quando você vê, já foi.
Apesar de um fluxo em específico ser mais difícil de seguir (experimenta debugar em Smalltalk q vc vai entender do que eu estou falando), os métodos todos são tão simples que você consegue entendê-los em segundos.
A segunda parte da proposição: "mantenha a responsabilidade vaga", significa que você deve desconfiar de especificações do tipo "o objeto deve persistir em banco todas as entradas". Isso porque ele contém detalhes de implementação, na verdade, o que interessa para os outros objetos não é como a informação vai ser guardada, mas como ela vai ser recuperada. Uma especificação melhor seria "o objeto deve saber informar as entradas feitas". Se isso será feito em banco de dados, em arquivo texto, distribuído na rede ou por sinal de fumaça, não interessa, o que nos dá muito mais flexibilidade.
No final a idéia é aumentar o reuso. Evitando responsabilidades e delegando o trabalho, na verdade estou procurando reutilizar o que outras classes já fazem. Mantendo as responsabilidades vagas estou escondendo como faço as coisas (encapsulamento).
