Dúvida: Que Design Pattern devo usar?

Assuntos Gerais Agile
#1

Olá pessoal,

Tenho uma dúvida e espero que possam me ajudar…

A regra de negócio que preciso modelar em um diagrama de classes é a seguinte: vamos supor que eu precise determinar o preço de um produto em um pedido, porém, há vários registros de preço/regras de preço, e apenas um destes registros serve para o produto no pedido. Para que um destes registros seja o ideal para o pedido, é lido um a um destes registros e o registro que tiver maior numero de informações em comum com o pedido, ou seja, que possua a maior pontuação, é eleito o registro que determinara o preço do produto no pedido.

Pensei em ter a classe “PedidoVenda” como cabeçalho do pedido, a classe “PedidoItem” para os itens do pedido, e uma classe chamada “RegrasNegocio”, onde nela eu consolidaria todas as regras de calculo de pedido, incluindo a de preço descrito acima. A classe “RegrasNegocio” leria as regras de preço e jogaria no item do pedido o preço calculado.

Alguém sabe qual melhor pattern que se encaixa neste conceito?

#2

Seu texto diz que vc precisa de uma estrutura genérica polimórfica, mas não da informações suficientes para apontar para um cenário de patterns.
Talvez um strategy ou template method se encaixe…

#3

Acredito que o padrão State também possa ser utilizado nesse cenário.

#4

[quote=erickles]Olá pessoal,

Tenho uma dúvida e espero que possam me ajudar…

A regra de negócio que preciso modelar em um diagrama de classes é a seguinte: vamos supor que eu precise determinar o preço de um produto em um pedido, porém, há vários registros de preço/regras de preço, e apenas um destes registros serve para o produto no pedido. Para que um destes registros seja o ideal para o pedido, é lido um a um destes registros e o registro que tiver maior numero de informações em comum com o pedido, ou seja, que possua a maior pontuação, é eleito o registro que determinara o preço do produto no pedido.

Pensei em ter a classe “PedidoVenda” como cabeçalho do pedido, a classe “PedidoItem” para os itens do pedido, e uma classe chamada “RegrasNegocio”, onde nela eu consolidaria todas as regras de calculo de pedido, incluindo a de preço descrito acima. A classe “RegrasNegocio” leria as regras de preço e jogaria no item do pedido o preço calculado.

Alguém sabe qual melhor pattern que se encaixa neste conceito?[/quote]

eu li por alto e pensei em um strategy com algum pattern de criação de objetos montando-o, como um abstract factory por exemplo ou um builder ou algo relativo a isso… eu sou meio suspeito (eu tenho uma propensão a ver strategy em tudo… :lol:

#5

[quote=maior_abandonado][quote=erickles]Olá pessoal,

Tenho uma dúvida e espero que possam me ajudar…

A regra de negócio que preciso modelar em um diagrama de classes é a seguinte: vamos supor que eu precise determinar o preço de um produto em um pedido, porém, há vários registros de preço/regras de preço, e apenas um destes registros serve para o produto no pedido. Para que um destes registros seja o ideal para o pedido, é lido um a um destes registros e o registro que tiver maior numero de informações em comum com o pedido, ou seja, que possua a maior pontuação, é eleito o registro que determinara o preço do produto no pedido.

Pensei em ter a classe “PedidoVenda” como cabeçalho do pedido, a classe “PedidoItem” para os itens do pedido, e uma classe chamada “RegrasNegocio”, onde nela eu consolidaria todas as regras de calculo de pedido, incluindo a de preço descrito acima. A classe “RegrasNegocio” leria as regras de preço e jogaria no item do pedido o preço calculado.

Alguém sabe qual melhor pattern que se encaixa neste conceito?[/quote]

eu li por alto e pensei em um strategy com algum pattern de criação de objetos montando-o, como um abstract factory por exemplo ou um builder ou algo relativo a isso… eu sou meio suspeito (eu tenho uma propensão a ver strategy em tudo… :lol: [/quote]

Sua opinião do Strategy com os builders é válida, o TemplateMethod também é interessante, serviria para isolar as regras e criar uma biblioteca de regras. Vou conversar com a minha equipe sobre estas duas premissas e ver no que dá, valeu pela ajuda pessoal!

#6

Como assim de acordo com as informações do pedido. Pode dar um exemplo prático?

Exemplo:
A Vista 10,00
30/60 15,00
30/60/90 20,00

Ou então pode ter preços de acordo com o ICMS

ICMS 7% 15,00
ICMS 12% 20,00

Ou então de acordo com a quantidade

100 peças = 10,00
500 peças = 9,90
…

Trabalho com representantes comerciais e vejo bastante disso =) Cada fábrica tem um padrão diferente… É isso que você precisa?
Você deve primeiro identificar quais são os parametros que você usará para selecionar o preço.

#7

Sim, é bem isso. Vamos supor que o cliente seja de SP e o frete seja CIF, o preço seria R$ 15,00. Se o cliente for do RJ e o frete FOB, o preço sera de R$ 20,00.

#8

Eu fiz vários preços, por exemplo:

[code]public class Preco
{
private int codigo;
private double preco;
}

public class PrecoEstadoFrete extends Preco
{
private Estado estado;
private TipoFrete tipoFrete;
}[/code]

O cliente cadastro o preço falando por exemplo:

[quote]PrecoEstadoFrete
codigo = 1
preco = 15.00
estado = SP
frete = CIF

PrecoEstadoFrete
codigo = 2
preco = 15.00
estado = SP
frete = CIF
[/quote]

E existe uma configuração de parametros que o cliente informa qual tipo de preço a fábrica usa. E existe uma classe para selecionar os preços: ± assim

Se Fabrica.TipoPreco = 'PrecoEstadoFrete' Procura preco onde estado = pedido.getCliente().getEstado() AND frete = pedido.getTipoFrete(); ....

No entanto… isso trás alguns problemas as vezes… Por exemplo, no caso acima, se o cliente não estiver com o estado preenchido não irá trazer… Ou então, existem fábricas que trabalha com preços Atacado e Varejo, só que o cliente às vezes paga uma e outras vezes o outro (depende da negociação), ai fica complicado ter um modelo fixo assim…
Tem cada coisa…

Talvez uma solução seja você fazer assim (simplifique bastante não fica automática, mas fica bem flexível):

[code]public class TabelaPreco
{
private int codigo;
private string descricao;
}

public class Preco
{
private int codigo;
private double preco;
private TabelaPreco tabela;
}
[/code]

Assim, você pode cadastrar qualquer tipo de preço. Exemplo:

TabelaPreco
-1 | SP + CIF
-2 | SP + FOB

Preco
-1 | 1 | 15.00
-2 | 2 | 20.00

Assim, na hora de digitar o pedido o usuário seleciona a tabela de preço usada. Isso é ruim dependendo quem vai digitar os pedidos, pois pode induzir a erros… No meu caso essa última solução se mostrou a ideal.

Qualquer dúvida estou à disposição

Abraços,

#9

se vc depende do estado ser preenchido, vc pode ter um Observer que verifica a mudança desse estado. Eu recomendaria tb, fazer a diagramação em UML para que vc entenda o que tem, e como seria o ideal.

#10

LPJava,

Qual seria a utilidade desse Observer no estado? Na minha opinião, isso é desnecessário.

#11

Rafael,

No caso , o usuário não informa tabela de preço, o sistema faria isso tudo automaticamente.

Vamos supor, que no pedido o usuário informe o cliente e o tipo de frete. Através do cliente, podemos saber o estado de entrega do pedido, assim, o sistema calculara de todas as regras de busca de preço cadastradas, a que mais se encaixa no pedido, ou seja, uma regra em que a mesma diz que, por exemplo, para o estado de SP e o frete seja CIF, o preço é R$ 15,00 (exemplo esdruxulo).

Claro, há muitos outros atributos a serem avaliados…a cidade do cliente, o tipo de condição de pagamento, o estado de saida da mercadoria, enfim. A realidade que temos é: há varias regras de busca de preço cadastradas no sistema e apenas uma delas, a que se encaixa no pedido é que dirá o preço de um produto.

O ideal era um pattern em que fique flexível a manutenção desta regra…

#12

E o que é que vai determinar qual os parametros devem ser avaliados no pedido?

#13

[quote=RafaelViana]LPJava,

Qual seria a utilidade desse Observer no estado? Na minha opinião, isso é desnecessário.[/quote]

pelo que vi acima, o “estado” é algo importante para ele. E precisa saber se ele mudou. Se mudou faz alguma coisa. Mas, talvez o State tb seja uma boa opção.

#14