DEV Community

Discussion on: Programação procedural orientada a classes

Collapse
 
hilderjares profile image
Hilderjares(sid)

Penso eu que quando uma classe chega a ter esse tando de atributos, ela foi mal pensanda; é uma classe que tem muitas responsabilidades.

Thread Thread
 
cviniciussdias profile image
Vinicius Dias

Muito provavelmente, sim!

Thread Thread
 
mhgontijo profile image
Matheus Gontijo

Uhmmm sim! Até aqui todos concordamos plenamente ;- ) Quando o assunto são classes de negócios, +40 atributos é algo altamente doloroso. É muita "gente" envolvida para a mesma classe. Exemplo: EnvieEmailDeAniversario. Quebra SRP completamente.

O lance "desafiador" aqui é a ampla interpretação do problema... O que gostaria de saber é em relação a classes de "entidades"... Veja Pessoa, Corretor, Jogador, Cliente. Obviamente, podemos extrair e distribuir os atributos em diferentes responsabilidades. No entanto, é possível que mesmo após uma boa distribuição de responsabilidades, e um cuidado imenso em quais responsabilidades cada classe deve ter, tenhamos classes com muitos atributos. Vamos dizer que de ~60 atributos requisitados consigamos enxugar para 25, em algumas outras entidades. Ainda sim temos um número considerável de atributos no __construct. Essa foi a ideia inicial.

O que acham? Gostaria de ouvir vocês.

Thread Thread
 
cviniciussdias profile image
Vinicius Dias

Entendi seu ponto, mas continuaria sendo um caso de má abstração uma classe ter esse número de atributos.

Você consegue compartilhar um gist com um exemplo real pra poder analisar um ponto mais concreto?

:-D

Thread Thread
 
mhgontijo profile image
Matheus Gontijo • Edited

Opa, tem como sim! Obrigado pela resposta.

Poderíamos ter uma discussão altamente filosófica por mais de 30 anos a fim de chegar a um senso comum se "um ou outro" atributo deveria de fato pertencer a classe Pedido ou não. No entanto, com o intuito de tornar o exemplo mais fácil de ser compreendido, poderíamos assumir que esses atributos tem minimamente alguma relação com a classe Pedido?

Eu listei rapidamente 24 atributos que me vieram a mente. Por outro lado, eu acredito que uma grande empresa com 500/1.000/10.000 colaboradores, possuidora de um processo rico em detalhes e com abundantes regras de negócio poderia "facilmente" incrementar, pelo menos, uns 10 atributos na lista seguinte.

Segue a lista: pastebin.com/raw/8G4HxsE1

Alguma sugestão de abstração? Como podemos diluir esses 24 atributos em outras responsabilidades? Podemos chegar em 2-4 dependências?

Muito obrigado por seu tempo e pela thread, Vinicius!!!!!

Thread Thread
 
cviniciussdias profile image
Vinicius Dias • Edited

Eu que agradeço pela thread. Levanta pontos bem interessantes.

Então, concordo que todos os atributos possuem relação com a classe, mas isso não muda o fato de que ela pode estar mal abstraída. Eu preciso partir de algumas premissas pra poder pensar em algumas soluções... Só um expert de negócios poderia confirmar essas minhas premissas, mas vamos a alguns "chutes". hehehe

Data de criação e atualização são informações de persistência, não de domínio, logo não entram na entidade. São "atributos virutais", como alguns ORMs chamam.

Loja muito provavelmente seria o Aggregate Root que tornaria o acesso a Pedido possível, logo seria redundante ter esse atributo em Pedido.

  • Pontos cartão de presente
  • Pontos fidelidade
  • Disclaimers aceitos
  • Papel de presente ou embrulho
  • Retirada na loja
  • Arquivos anexados

Todos esses acima, se entendi corretamente o conceito do domínio, se enquadram em DetalhesPedido ou algo do tipo, mas pode ser mais discutido, claro. Posso ter entendido errado.

Subtotal e total são valores calculados baseando-se nos produtos. Uma estrutura de Composite poderia ser aplicada até para ter "pedidos aninhados".

Pedido pode significar muita coisa dependendo do domínio. Às vezes pode ter uma Compra que possui vários pedidos. Às vezes um cliente pode realizar apenas um pedido por data. Se esses forem os casos, o Aggregate Root muda, retirando alguns outros atributos da classe.

Aí teriamos que entrar numa discussão bem mais aprofundada sobre o caso.

Mas ainda assim, se existe uma classe com antos atributos, chances são grandes de nem todos serem obrigatórios. Aí, a criação fica completa, o que normalmente pede uma espécie de Creation Method (que o DDD chama de Factory), Builder ou algo do tipo.

:-D

Thread Thread
 
mhgontijo profile image
Matheus Gontijo

Insights massa, top!!! 👍👍👍👍👍👍👍

Thread Thread
 
cviniciussdias profile image
Vinicius Dias

Obrigado pela discussão. Realmente me fez refletir aqui sobre algumas decisões que tomamos corriqueiramente.