5 replies to this topic

[Nicholas Pufal]

Há tempos que venho lendo alguns livros sobre POO.

Um termo comumente utilizado é o de "modelo de negócios" (business model). No caso de uma aplicação baseada em MVC, a parte do "model" seria o business model. Até aí todos dizem, maravilha... Agora, o que seria de fato "modelo de negócios"? Eu ainda não achei uma explicação simples para isso. Em alguns casos parece que tem ligação com a requisição dos dados de um BD (no caso do MVC), enquanto que em outros dá a entender que é a lógica de negócio específica de uma aplicação, como por exemplo: em uma dada loja, é preciso implantar um sistema onde o valor do produto terá uma quantia de 10% agregada, que é a comissão do vendedor - estes casos específicos de cada negócio, são os que definem um modelo de negócios?

Outro item em que ainda tenho muita dúvida é em identificar uma composição e uma agregação. A teoria é barbada: na composição existe contenção, ou seja, assim que o pai é destruído, o filho também o será. No caso da agregação isso não acontece, visto que o objeto "parte" é instanciado de forma independente do "todo".

Agora, neste caso aqui, o que seria?

$venda = new Venda(3,new Produto(9.68,"Meu produto",3));

Eu considero como composição, visto que se o objeto venda for destruído, o objeto Produto também o será... Mas já vi livros dizendo que isso é agregação Alguém pode clarificar isso?

Outra coisa, já vi isso:

$produto = new Produto();
$produto->quantidade = 3;
$produto->id = 2;
$produto->nome = "Meu produto"

$venda = new Venda(3,$produto);

Ser declarado como uma composição... E não como uma agregação (que para mim parece ser mais coerente, seguindo os conceitos).

Alguém dá uma forcinha?

Valeu!

[Édipo Costa Rebouças]

Bom dia Fire, quando você esta trabalhando com um MVC por exemplo a parte do model business seriam as classes que cuidam da lógica do negocio e não se preocupam com a parte grafica e como o BD é implementado... esse parte dos 10%,faria parte do modelo de negocio.

na classe produto por exemplo, sendo uma classe de negocio ele não pode conter nada, nada que deixa ela dependente da parte gráfica, as saídas dela só podem ser dados.

na classe produto você tb não pode ter as querys do banco, então você teria que ter uma outra classe ProdutoBD, que trataria isso, sendo que você faz uma instanciação dentro da classe Produto, e chama o da classe ProdutoBD para fazer inserções, exclusão, etc...

Em java existem várias padronizações para essa parte, o DAO com o abstract Factory por exemplo, é uma delas.

Sobre as partes de agregação e composição, estou meio fraquinho em uml, mais tarde respondo, vou dar uma pesquisada, tem um livro que é bem fininho, mas é muito bom, é um do Matin Fowler, se você já não viu, vale a pena ver. http://compare.busca...8536304545.html

EDITADO

Na Composição a classe parte só existe se a classe Todo parte exister.

Exemplo:

Venda e Item venda

A classe Venda(todo parte) instancia item venda(parte) e item venda não existe sozinha.

Na agregação o item venda poderia exister sem a Venda.

Edição feita por: Édipo Costa Rebouças, 30/09/2009, 19:55.

[Nicholas Pufal]

Édipo, valeu pelo post, mas a teoria eu já entendi... Eu quero exemplos práticos, conforme postei acima, eu queria respostas aos exemplos que eu dei.

Tudo fica legal na teoria, e todo mundo sabe de cor de trás pra frente até, mas na prática muita gente troca tudo, não sabe analisar e é aí que tudo desanda.

Com relação ao modelo de negócios o que eu venho lendo é que ele é responsável pelas particularidades da aplicação.

Vou esperar alguém responder aos 3 exemplos que dei (modelo de négocios, agregação e composição) para que isso possa ficar claro.

[Édipo Costa Rebouças]

Fire, independete do código que você fez, se na sua lógica, o produto depender da venda para "viver", se ele não existir sem a venda é composição, mesmo que sou código deixei ou não isso muito claro, idependente de como o código foi escrito, se respeitar essa regra é composição.

O modelo de négocio, se você tirar o MVC da cabeça, é como o seu negocio funciona, você pode reprentar isso de diversas maneiras: como fluxogrmas, diagrmas de casos de uso, etc.... é independente da linguagem de programação. no mvc é a parte que fica entre a camada de dados e o controller, sendo que ele só tem as variaveis, métodos de acesso a essas variaveis e logicas de nogocio, como o calculo de juros, para puxar algum do banco, você deve usar algum padrão de acesso a banco, como o DAO ou o AbstractFactory.


Um exemplo de quando um visitante entra no seu site por exemplo:

Browser ---> Controller ----> CamadaNegocio-->PadraoDeAcessoBD-->BD--->PadraoDeAcessoBD--->CamadaNegocio--->Controller--->View

o controller gerencia que view ele vai mostrar, seja um front end web normal, mobile, applet, etc...

É dificil falar de prático, pois são coisas teoricas aplicadas a diversas linguagens, e de diversas maneiras, com frameworks que as vezes não deixam vc ver algumas dessas camadas.

Edição feita por: Édipo Costa Rebouças, 01/10/2009, 15:42.

[Nicholas Pufal]

Hmm interessante você dizer isso... eu sempre achei que estes conceitos de agregação, composição e etc fossem baseados no que está escrito, e não no background, isto é, a parte teórica que permite desenvolver o código. Mas ainda assim para mim não faz muito sentido existirem tais conceitos, se o que está escrito (código) não condiz.

Como que alguém pode chamar o relacionamento de um objeto produto com o objeto vendas, onde existe contenção no código (como no exemplo que eu dei, o primeiro deles de uma linha) , de agregação e não de composição?

Para mim se o objeto foi criado através do construtor de outro objeto, é relação clara de composição...

Pode até ser muita teoria, mas tô lendo bastante sobre design patterns, e essa troca de conceitos tá complicando muito.

EDIT:

Tava pensando cá com meus botões... Então na verdade o conceito de composição não é algo como "Se NotaFiscal não existir, não existe ItemNotaFiscal", e sim algo como "Se NotaFiscal não existir, logo não tem sentido de ItemNotaFiscal existir". Certo? Seria a mesma coisa que uma classe que gerencie apenas telefones para objetos pessoa. Não existe sentido de um objeto telefone existir, se não existe uma pessoa... logo, pode ser considerado composição, independente de como estiver escrito no código.

Essa teoria toda é mais como uma guia, para o programador quando ver uma UML, ter uma idéia de como proceder, entender a relação. É isto?! Finalmente captei?

Edição feita por: Nicholas Pufal, 07/10/2009, 11:04.

[Édipo Costa Rebouças]

exato.

Edição feita por: Édipo Costa Rebouças, 07/10/2009, 16:40.