Além de ignorantes, apáticos e egoístas, bons objetos são tímidos.

É o que dizem os Programadores Pragmáticos (Andy Hunt e Dave Thomas), no artigo de 2003 The Art of Enbugging:

O objetivo fundamental é escrever código tímido: código que não revela muito de si pra ninguém e não conversa com os outros mais do que o necessário.

Código tímido evita contato com os outros, não é como aquele vizinho fofoqueiro que está envolvido nas idas e vindas de todo mundo.

Código tímido nunca mostraria suas coisas “privadas” para os “amigos”, como alguns códigos C++ mais promíscuos fazem.

Escrever código tímido é apenas um pequeno começo para evitar a introdução de bugs, mas realmente ajuda.

Assim como no mundo real, boas cercas fazem bons vizinhos – contanto que você não olhe pela cerca.

O título do artigo, algo como “A arte de enbugar”, parte da ideia que, num dia ruim, o programador se sente “enbugando” o código: inserindo bugs. E o pior é que não inserimos bugs diretamente mas criamos as condições que depois nos induzirão a criar bugs.

Citam uma frase de Alec Sharp:

Código procedural tende a obter informações e, em seguida, tomar decisões baseadas nessas informações.

Código OO diz a objetos que façam coisas.

O código procedural era o antagonista preferido de OO, antigamente.

Em seguida, explicam a famosa frase Tell, Don’t Ask (algo como “Diga, não pergunte”):

Envie comandos para objetos dizendo o que você quer fazer.

Explicitamente, não queremos consultar um objeto sobre seu estado, tomar uma decisão e, então, dizer ao objeto o que fazer.

Para explicar melhor a ideia, citam a analogia “O Entregador de Jornais e a Carteira”, de David Bock:

Suponha que o entregador de jornais chegue à sua porta, exigindo o pagamento da semana. Você se vira e o entregador de jornais tira sua carteira do bolso de trás, pega dois dólares e coloca a carteira de volta.

Por mais absurdo que pareça, muitos programas são escritos nesse estilo, o que deixa o código aberto a todos os tipos de problemas (e explica por que o entregador de jornais agora está dirigindo um Lexus).

Falam ainda da ideia de Command/Query Separation, originada por Bertrand Meyer, pioneiro de OO e criador da linguagem Eiffel e do Open/Closed Principle:

Uma rotina agindo como um comando (command) provavelmente alterará o estado do objeto e também poderá retornar algum valor útil por conveniência.

Uma consulta (query) apenas fornece informações sobre o estado do objeto e não modifica o estado visível externamente do objeto. Ou seja, as consultas devem estar livres de efeitos colaterais, como visto do mundo exterior [de fora do objeto].

Arrematam com uma explicação da Lei de Demetra:

A Lei de Demetra afirma que todo método de um objeto deve chamar apenas métodos pertencentes a:

  • si mesmo
  • quaisquer parâmetros que foram passados para o método
  • quaisquer objetos criados
  • qualquer composição

Curiosidade: Demetra era a deusa grega da Agricultura. Mas o nome não tem nada a ver com isso: era o nome de um sistema e um projeto de pesquisa da Northeastern University, de Boston, que, por acaso, estudava Aspect Oriented Programming (AOP).