Aggregation X Delegation - round 2

De volta ao assunto do como montar objetos "compostos".

Como regra geral eu gosto bem mais da solução de Delegação. Acho mais elegante, mais conforme os princípios de OO, e de mais fácil compreensão também. Mas como eu já disse, isso é apenas minha opinião. E a sua, leitor, qual é?

É fato também, que a solução de Agregação tem lá o seu lugar ao sol. Por exemplo: como definir o DisplayMember e o ValueMember de um WinForm.ComboBox com objetos compostos? Algo como ...

cboMeuComboBox.ValueMember = oMeuObjeto.SubObjeto.Id;
cboMeuComboBox.DisplayMember = oMeuObjeto.SubObjeto.Descricao;

... simplesmente não funciona. Nesse caso, eu acabo adotando a agregação, e fica mais ou menos assim:

cboMeuComboBox.ValueMember = oMeuObjeto.SubObjeto_Id;
cboMeuComboBox.DisplayMember = oMeuObjeto.SubObjeto_Descricao;

Isso mesmo, agrego as propriedades de SubObjeto diretamente como propriedades em MeuObjeto. É estranho e poluído, mas funciona 100%.

Atualmente eu tenho preferido sempre a solução de Delegação. Mas nesses casos mais particulares, não tem jeito... uso mesmo a Agregação. E claro, isso só comprova a nossa velha teoria, que "não existe bala de prata".

Até a próxima,

Aggregation X Containment/Delegation

Eu sempre tenho essa dúvida na hora de construir meus objetos. Às vezes prefiro delegação. Outras Agregação. A quem é novo em POO, aqui vai um breve esclarecimento:

Problema:
Você tem uma entidade chamda "Cliente". Seus atributos são Nome, CPF e DataNascimento. Você também precisa de um atributo EstadoOrigem (unidade da federação onde o cliente se cadastrou). Você ia criar um atributo EstadoOrigem, do tipo string (onde você imagina armazenar a sigla, com dois caracteres), mas acabou de enxergar que Estado é um entidade tão importante no sistema, a ponto de ser representada realmente como uma entidade. :-)

Você faz uma pausa em Cliente e modela a entidade Estado: NomeEstado e Sigla (vamos deixar todos os IDs fora de questão por enquanto, ok?).

Com a entidade Estado na mão (que vai virar uma classe durante a programação), você olha de volta para cliente e pensa: Como vou representar o estado de origem do cliente?


Solução 1: Agregação
Uma solução, chamada de Agregação, é agregar os atributos da "sub-entidade" na "entidade-raiz". Ou seja: Cliente teria os seguintes atributos Nome, CPF, DataNascimento, NomeEstado, SiglaEstado.

Efeitos colaterais? agora precisamos representar a UF de nascimento do cliente. Teríamos 2 NomeEstado e 2 SiglaEstado. Poderíamos nomear o segundo par de atributos como NomeEstadoNascimento e SiglaEstadoNascimento. O nome seria bastante claro, mas o primeiro par não está tão claro assim. Então seria melhor renomear o primeiro para NomeEstadoOrigemCadastro e SiglaEstadoOrigemCadastro.

Alguns puristas diriam que esta abordagem fere um dos princípios básicos de origentação à objetos (encapsulamento). É verdade, eu também acho que fere, mas é um "mal necessário", às vezes.


Solução 2: Delegação (ou Contenção ou Composição)
Outra solução é compor a entidade Cliente com outra(s) entidades, na forma de atributos. Então Cliente teria os seguintes atributos: Nome, CPF, DataNascimento e EstadoOrigem, sendo que EstadoOrigem tem os atributos NomeEstado e SiglaEstado.

Nas linguagens de programação (a maioria) ficaria algo assim:

txtValor.Text = objCliente.EstadoOrigem.NomeEstado

Eu gosto mais dessa abordagem. Escreve-se menos, é mais clara (eu acho esse código mais limpo). Mas a prática mostra que isso tem lá os seus drawbacks.


Conclusão
Como eu já conheço alguns pontos positivos e negativos das duas formas, eu vou usando aquela que eu acho que vai se encaixar melhor em cada caso. Ou seja, eu não tenho uma solução única para todos os casos. "Não existe bala de prata", mas sim, a ferramenta certa para o trabalho certo.

Eu vou voltar a este assunto mais tarde, mas antes queria saber das opiniões dos leitores... que abordagens preferem e seus motivos.

Até a próxima.

LZ