Melhores práticas para implementar uma associação do tipo agregação.

Question

Pessoal,

Estou desenvolvendo e documentando um sistema em UML, e tenho uma dúvida sobre como implementar uma associação entre objetos em .NET.

Meu exemplo é um carrinho de compra que possui produtos. Existe uma associação do tipo agregação entre a classe carrinho de compra e produto. Implementando este modelo em C# é que surge a dúvida sobre qual a melhor prática:

1. Devo criar o seguinte atributo na classe CarrinhoCompras para representar a agregação:

private Collection<Produto> Produtos;

OU

2. Devo criar uma classe isolada para armazenar a coleção de produtos, e referenciar somente este "container de produtos" na classe CarrinhoCompras:

class ListagemProdutos
{

private Collection<Produto> Produtos

}

class CarrinhoCompras
{

private ListagemProdutos produtos;

}

Conto com a ajuda/experiência de vcs e obrigado pela atenção!

Answer 1

  No meu ponto de vista, o ideal era:

class Produtos : List<Produto>
{
     //Se precisar sobrescreva os métodos Add , remove e etc.
     //Permite criar métodos do tipo FindByName na lista de produtos
}

class Compra
{
       private Produtos produtos;
}

---

Bruno Gallego - Se este poste foi útil, por favor, classifique

Answer 2

Bruno,

Obrigado por compartilhar sua opinião.

Quanto a disposição destas classes no projeto, vc criaria a classe Produtos e Produto no mesmo arquivo? (produto.cs no meu caso)?
Como vc organizaria as classes?

Abraço.

Answer 3

Creio que a classe que armazena os itens do carrinho de compra seria a classe itemDePedido que tem as propriedades "quantidade" e "codProduto". Além disso pode trazer o produto como propriedade ou expor os campos relevantes para as funções de carrinho de compras.

Utilize a fonte de dados do carrinho, cookies ou session, para manipular a classe final do pedido enquanto carrinho de compras.

Considero que o carrinho de compras é um pedido em construção.

Quanto a organização dos arquivos eu sempre uso e recomendo um arquivo pra cada classe.

Answer 4

Fábio,

    No mesmo arquivo não. Não é boa prática colocar + de uma "coisa" no mesmo arquivo. Uma classe por arquivo. As vezes até mesmo um arquivo só com um Enum. Se eu fosse dar manutenção um dia, nunca iria imaginar q a lista de produtos estivesse no mesmo arquivo de produtos. Por este motivo q não é bom colocar várias coisas no mesmo arquivo.

    * Outra boa prática é não colocar preposição e verbo no nome da classe. É uma boa criar a classe ItemPedido / ItemCompra.
   Pq se for Compra com Produto. A quantidade comprada estaria onde??? No produto ?? A quantidade no Produto dá entender q é o a quantidade em estoque e não a quantidade comprada.

    * Outra obs.: Não aconselho colocar codProduto na classe ItemPedito. Colocaria produto do tipo Produto.

---

Bruno Gallego - Se este poste foi útil, por favor, classifique

Answer 5

Carlos,

Obrigado pela sua visão. Também considero que o carrinho é um pedido em contrução, por isso devo ter basicamente três classes: CarrinhoCompra, ItemCompra, Produto. Vou seguir as recomendações a respeito da organização de arquivos.

Bruno,
Entendi suas dicas, mais uma vez obrigado. Algumas já sigo e outras são novas.
Uma dúvida: concordo que quantidade não é um atributo de Produto, e sim de ItemCompra. Aí minha pergunta: mesmo que eu precisasse de QuantidadeEmEstoque como atributo, ela não deveria estar em Produto, certo? No sentido puro do objeto produto, ele não tem quantidade como uma qualidade ou atributo, logo, vou precisar de algo como Estoque.ObterQuantidade(Produto) ? Estaria certo isso?

Existe algum livro, artigo, webcast com estas recomendações de melhores práticas de modelagem? Normalmente os livros ensinam UML basicamente, porém dicas como a do Bruno sobre não utilização de verbos e preposições em classes é muito valiosa para a qualidade final do projeto. Eu já trabalho dessa forma, mas descobri por si só que não "soava bem" verbos e prep. como nome de classe, tornando os diagramas de UML um tanto confuso.

Acredito que este é o tipo de ajuda que estou buscando. Se vc tem dicas assim, compartilhe com a comunidade e ajude-nos a melhorar a forma como modelamos nossos softwares.

Obrigado, e abraço a todos!!

Answer 6

Fábio,

    Em relação a sua primeira dúvida: Não há um modelo específico q deve ser sempre seguido. O modelo varia de acordo com o negócio proposto. Pode ser correto colocar quantidade no produto, mas se vc identificar a necessitade de ter uma entidade Estoque, tb está correto.

    Em relação a nomenclaturas, não há nenhuma específica, há +- um padrão (não um exato).
    Ex.: Neste link http://msdn.microsoft.com/en-us/library/ms978384.aspx  é algo q a microsoft recomendo para arquiteturas. Como disse "recomenda", não vc deva seguir, isto varia de acordo com suas necessidades, como citei na modelagem.

    Eu sigo o padrão da empresa, q é quase = o da petrobrás. Por isso q digo q os padrões de nomenclatura são parecidos, mas não um único.
    Ex.: Em relação aos verbos este é praticamente padrão único. Pq verbo no nome da classe é método. Ex.: Classe chamada "DisponibilizarArquivo".
    Isso é um método q vai enviar arquivo para algum lugar ...   O nome da classe poderia ser algo do tipo "Arquivo" com o método Disponibilizar.

---

Bruno Gallego - Se este poste foi útil, por favor, classifique