Clean Code e a assimetria entre objetos e estruturas de dados

Talvez ns desenvolvedores tenhamos ouvido ou at reproduzido bastante a afirmao de que tudo na programao objeto. O captulo 6 do livro Clean Code, escrito pelo Robert C. Martin (tambm conhecido como Uncle Bob, ou tio Bob), explica porque nem sempre precisamos de objetos, s vezes precisamos somente de simples estruturas de dados e qual a diferena entre os dois conceitos.

Introduo

O captulo comea questionando o porqu dos desenvolvedores exporem variveis privadas como se fossem pblicas atravs de mtodos acessores (gets and sets), mesmo quando se quer preservar essas variveis para que no gere dependncia.

Abstrao de Dados

A abstrao de dados super importante para que ocultemos os detalhes de nossos dados. Para isso, no utilizamos meramente mtodos de escrita e leitura dos dados, isso faria com que ficassem expostos, nem to somente trata-se de manipulao de mtodos e funes. necessrio um entendimento da melhor maneira de manipular a essncia dos dados que um objeto contenha, de maneira em que a implementao deste permanea oculta.

Antissimetria data/objeto

• Objetos ocultam seus dados atravs de abstraes e expem mtodos que manipulam esses dados.

• Estruturas de dados expem seus dados, mas suas funes no so significativas.

  Ou seja, basicamente, as definies de objeto e estrutura de dados so quase que complementares.

Em resumo:

• Em estruturas de dados, temos facilidade de adio de novas funes sem precisar alterar as estruturas de dados existentes, enquanto no cdigo orientado a objeto, a facilidade est em adicionar novas classes sem alterar os mtodos existentes.

• Em estruturas de dados, temos dificuldade em adicionar novas estruturas de dados, pois demandaria a alterao de todas as funes. Enquanto que na programao orientada a objeto, a dificuldade est em adicionar novos mtodos, pois demandaria a alterao das classes existentes.

O que difcil em orientao a objeto fcil para estruturas de dados e vice-versa. Assim, podemos tratar cada caso de acordo com o que for cabvel e adequado.

Em casos em que desejamos adicionar novos tipos de dados sem alterar a funo, o ideal seria utilizar a orientao a objeto, enquanto em casos em que desejamos adicionar novas funes mantendo os dados preservados, ento estruturas de dados so mais adequadas.

Isso acaba respondendo o que foi questionado no incio e desmistificando a afirmao de que em programao tudo um objeto. Muitas vezes temos e desejamos estruturas de dados simples com funes operando sobre elas.

Lei de Demeter

A lei de Demeter uma heurstica (heurstica: mtodo que utiliza a pesquisa e prtica para descobrir novos conceitos e provar fatos em busca de resposta para questes complexas) que afirma que um mdulo no deve enxergar o interior dos objetos que ele manipula. Objetos abstraem os dados e expem as operaes sobre eles, ou seja, devem ocultar sua estrutura externa e no exp-la atravs de mtodos acessores.

Mais precisamente, se temos uma funo f em uma classe C, este s deve chamar mtodos de:

• C
• Um objeto criado por f
• Um objeto passado por parmetro para f
• Um objeto dentro de uma varivel de instncia C

Train Wrecks

Quando temos um cdigo com mtodos acoplados, como por exemplo:

const cep = ctx.getPessoa().getEndereco().getCep()

Chamamos de Train Wreck, pois a estrutura se comporta como um conjunto de vages acoplados, se assemelhando a um trem. Esse tipo de cdigo considerado descuidado e inapropriado. O ideal seria escrevermos dessa maneira:

const pessoa = ctx.getPessoa();

const endereco = pessoa.getEndereco();

const cep = endereco.getCep();

A funo getCep() possui acesso a muita informao em nveis aos quais no deveria ter acesso, certamente tem conhecimento de que o objeto ctx possui pessoas, que por sua vez possuem objetos do tipo endereco e, por consequncia, possuem objetos do tipo cep.

Se isso uma violao da lei de Demeter, depender se ctx, pessoa, endereco e cep so simples estruturas de dados ou objetos. Caso sejam objetos, no deveriam estar expondo sua estrutura interna, esta deveria estar oculta. Portanto, a informao sobre o seu interior viola a heurstica. Por outro lado, caso sejam estruturas de dados simples, sua implementao interna naturalmente exposta, no violando essa lei.

Esse questionamento acaba sendo menos confuso quando estruturas de dados simplesmente tem variveis pblicas e nenhuma funo, enquanto objetos tem apenas variveis privadas e funes pblicas. Porm existem frameworks e padres (como, por exemplo, o padro beans) que demandam mtodos acessores e de alterao, mesmo em estruturas de dados simples.

Hbridos

Estruturas hbridas so compostas por parte objeto e parte estruturas de dados. Essa configurao ruim pois acaba expondo variveis internas, fazendo com que funes externas tenham acesso a essas variveis como numa estrutura de dados, assim como funes significativas e exposio de mtodos acessores. O que dificulta tanto a adio de novas funes como a criao de novas estruturas de dados. So estruturas confusas, que no possuem coerncia e devem ser evitadas.

Estruturas Ocultas

Devemos evitar que estruturas internas sejam expostas dentro de um objeto, ou que este no acabe se sobrecarregando de mtodos para tratar informaes. Para isso, utilizamos estruturas ocultas, mtodos que lidem com a manipulao dessa estrutura sem exp-la ou comprometer a sua abstrao.

Objetos de Transferncia de Dados

Os DTOs, ou objetos de transferncia de dados, so basicamente classes que possuem variveis pblicas e nenhuma funo. So estruturas teis, especialmente para se comunicar com banco de dados ou analisar sintaticamente mensagens provenientes de sockets. So teis para converter dados brutos vindos do banco de dados em objetos no cdigo do aplicativo.

Active Record

Active Records so formas especiais de DTOs. So estruturas de dados com variveis pblicas, mas tipicamente possuem mtodos de navegao como find e save. Os Active Records so tradues diretas das tabelas de bancos ou outras fontes de dados.

A soluo para evitar que essas estruturas sejam tratadas como objetos, criando um hbrido entre uma estrutura de dados e um objeto, tratar o Record Active como uma estrutura de dados e criar objetos separados que contenham as regras de negcio e ocultem seus dados internos.

Concluso

• Objetos expem aes e ocultam seus dados, facilitando a adio de novos tipos de objetos sem modificar os mtodos existentes e dificulta a incluso de novas atividades em objetos existentes.
• Estruturas de dados expem dados e no possuem aes significativas, facilitando a adio de novos mtodos sem afetar os dados existentes e dificultando a adio de novas estruturas em funes existentes.

Em um sistema, desejvel que haja flexibilidade para adicionar novos tipos de dados, para isso prefere-se o uso de objetos. Em outras ocasies, queremos flexibilidade para adicionar novas aes, sendo prefervel optar pela estrutura de dados e procedimentos. Portanto, cabe a ns desenvolvedores entendermos e decidirmos pela melhor estrutura aplicvel no momento.