Refletindo sobre ToString() e models

Olá pessoal, tudo certo?

No post de hoje gostaria de trocar uma ideia sobre encapsulamento, POCOs/POJOs e SRP (Single Responsibility Principle).

Estou lendo o livro Clean Code de Robert Martin (que é uma boa leitura) e gostaria de refletir sobre alguns pontos que percebi durante a leitura. Antes de tudo, gostaria de colocar algumas ideias sobre o que vemos em aplicações e como isso se assemelha a alguns pontos do livro. Vou utilizar C# como linguagem do post, mas imagino o mesmo valha para Java.

Imagino que isso já deva ter sido discutido em outros lugares, mas desconheço essas possíveis discussões!

Vamos ao que interessa! Em linguagens como C# e Java os objetos possuem métodos ToString() e Equals(), que servem para representá-los na forma de string e comparar igualidade, respectivamente. Quando aprendi pela primeira vez que usávamos o ToString() para retornar a representação em string de um objeto fiquei perplexo com a simplicidade que seria para modificar alguns pontos do código, apenas mudando ToString(). Entretanto, se olharmos para Equals(), qual deveria ser a regra? Ao meu ver, Equals() de objetos devem retornar true somente se os objetos forem a mesma instância. Para isso, no C# existe ReferenceEquals() e deve haver um mesmo método no Java. No caso de listas que possuem os mesmos valores, deveria retornar true por terem os mesmos valores ou false por serem instâncias diferentes?

A ideia do parágrafo anterior também vem de que utilizamos objetos de modelo (Model) com regras de comparação. Algo que ficou muito evidente nos últimos tempos (a princípio no ASP.NET MVC) é a utilização de POCOs com Entity Framework, ou seja, temos uma classe que serve como uma estrutura de dados (deveria ser uma struct?) e deixamos esta classe com propriedades públicas para set e get (setters e getters no Java). Desta forma, se pensarmos que um objeto de modelo além de armazenar dados (propriedades) também deve saber fazer a sua comparação e representação em string, isso não viola SRP?

A principal ideia, é que os métodos ToString() e Equals() vieram da ideia do encapsulamento, que em classes de modelo geralmente não existe, então por que implementar estes métodos nestas classes? Não seria mais prático ter uma interface IStringfier<T> e uma interface IEquatable<T> para estas implementações? Desta forma tiraríamos a regra de representação das classes de modelo.

Continuo concordando que estas implementações devem continuar em suas classes e seus respectivos métodos (Lendo Clean Code, existe um ponto que se fala de coesão1, onde poderíamos perceber que ToString() e Equals() deveriam ficar em suas devidas classes). Este post é apenas um reflexão, também para ver o que os demais desenvolvedores acham da ideia.

Enfim, este era o post. E você, o que acha da ideia?

Abraço e até a próxima!

1 Coesão é o relacionamento entre métodos e atributos de uma classe. Quanto mais atributos da classe um determinado método utilizar, mais coesos eles estão. Quando a coesão for baixa, pode ser um indicador para extrair uma nova classe.

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 )

Imagem do Twitter

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

Foto do Facebook

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

Foto do Google+

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

Conectando a %s