Design, OO

Código tímido

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).

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

w

Conectando a %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.