Strategy com o quê?

classic Classic list List threaded Threaded
42 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Strategy com o quê?

sidtj
[first post here]

Pessoal, estou tentando aqui com a galera do python (que estou
estudando há alguns dias).
A tendência é ter mais entendidos de OOP aqui do que no outro grupo
onde postei essa dúvida.
Se alguém puder ajudar agradeço muito:

Tenho um sistema de pagamentos.
Nele preciso criar um esquema com estratégias de desconto.
Então resolvi usar o Strategy assim:

<<interface>> (ou abstract)
IEstrategiaDeDesconto
public getTotalDoDesconto(Venda v)

Agora as implementações:

class DescontoPorTotalMaiorQueX

class DescontoPorCupom

class DescontoPorFormaDePagto


Como a Venda contém informações sobre os produtos, seus valores e etc
isso funciona bem. Quando quero o total apenas chamo o método
getTotalDoDesconto()  da implementação de desconto que
estiver em uso.

A questão é:
Como eu poderia COMBINAR múltiplas formas de desconto simultaneamente?
O modelo atual apenas
permite usar uma por vez.

Seria melhor criar um array dentro de Venda contendo as implementações
de desconto em uso e depois loopar para somar o total dos descontos pra então
aplicar ao total do pagamento?

Ou há algum jeito melhor de fazer isso (com menos acoplamento) talvez
usando um Decorator ou outro padrão de projeto? Qual outro? Como
seria?

Alguém já deve ter passado por isso.
Valeu pessoal.
Reply | Threaded
Open this post in threaded view
|

Re: Strategy com o quê?

Rodrigo Ferreira de Souza-2
No python todas as funções são objetos, o que significa que voce não precisa
criar o padrão strategy.. só passar a função como parâmetro como se fosse
uma variável qualquer.

2011/7/12 <[hidden email]>

> **
>
>
> [first post here]
>
> Pessoal, estou tentando aqui com a galera do python (que estou
> estudando há alguns dias).
> A tendência é ter mais entendidos de OOP aqui do que no outro grupo
> onde postei essa dúvida.
> Se alguém puder ajudar agradeço muito:
>
> Tenho um sistema de pagamentos.
> Nele preciso criar um esquema com estratégias de desconto.
> Então resolvi usar o Strategy assim:
>
> <<interface>> (ou abstract)
> IEstrategiaDeDesconto
> public getTotalDoDesconto(Venda v)
>
> Agora as implementações:
>
> class DescontoPorTotalMaiorQueX
>
> class DescontoPorCupom
>
> class DescontoPorFormaDePagto
>
> Como a Venda contém informações sobre os produtos, seus valores e etc
> isso funciona bem. Quando quero o total apenas chamo o método
> getTotalDoDesconto() da implementação de desconto que
> estiver em uso.
>
> A questão é:
> Como eu poderia COMBINAR múltiplas formas de desconto simultaneamente?
> O modelo atual apenas
> permite usar uma por vez.
>
> Seria melhor criar um array dentro de Venda contendo as implementações
> de desconto em uso e depois loopar para somar o total dos descontos pra
> então
> aplicar ao total do pagamento?
>
> Ou há algum jeito melhor de fazer isso (com menos acoplamento) talvez
> usando um Decorator ou outro padrão de projeto? Qual outro? Como
> seria?
>
> Alguém já deve ter passado por isso.
> Valeu pessoal.
>  
>


[As partes desta mensagem que não continham texto foram removidas]



------------------------------------

Python-Brasil
http://www.python.org.br/wiki/AntesDePerguntar
Links do Yahoo! Grupos

<*> Para visitar o site do seu grupo na web, acesse:
    http://br.groups.yahoo.com/group/python-brasil/

<*> Para sair deste grupo, envie um e-mail para:
    [hidden email]

<*> O uso que você faz do Yahoo! Grupos está sujeito aos:
    http://br.yahoo.com/info/utos.html


Reply | Threaded
Open this post in threaded view
|

Re: Strategy com o quê?

Rodrigo Ferreira de Souza-2
In reply to this post by sidtj
Para combinar várias opções de desconto, sugiro dar uma lida no padrão
decorator, com ele voce consegue esse comportamento.

Atenciosamente,
Rodrigo

2011/7/12 <[hidden email]>

> **
>
>
> [first post here]
>
> Pessoal, estou tentando aqui com a galera do python (que estou
> estudando há alguns dias).
> A tendência é ter mais entendidos de OOP aqui do que no outro grupo
> onde postei essa dúvida.
> Se alguém puder ajudar agradeço muito:
>
> Tenho um sistema de pagamentos.
> Nele preciso criar um esquema com estratégias de desconto.
> Então resolvi usar o Strategy assim:
>
> <<interface>> (ou abstract)
> IEstrategiaDeDesconto
> public getTotalDoDesconto(Venda v)
>
> Agora as implementações:
>
> class DescontoPorTotalMaiorQueX
>
> class DescontoPorCupom
>
> class DescontoPorFormaDePagto
>
> Como a Venda contém informações sobre os produtos, seus valores e etc
> isso funciona bem. Quando quero o total apenas chamo o método
> getTotalDoDesconto() da implementação de desconto que
> estiver em uso.
>
> A questão é:
> Como eu poderia COMBINAR múltiplas formas de desconto simultaneamente?
> O modelo atual apenas
> permite usar uma por vez.
>
> Seria melhor criar um array dentro de Venda contendo as implementações
> de desconto em uso e depois loopar para somar o total dos descontos pra
> então
> aplicar ao total do pagamento?
>
> Ou há algum jeito melhor de fazer isso (com menos acoplamento) talvez
> usando um Decorator ou outro padrão de projeto? Qual outro? Como
> seria?
>
> Alguém já deve ter passado por isso.
> Valeu pessoal.
>  
>


[As partes desta mensagem que não continham texto foram removidas]



------------------------------------

Python-Brasil
http://www.python.org.br/wiki/AntesDePerguntar
Links do Yahoo! Grupos

<*> Para visitar o site do seu grupo na web, acesse:
    http://br.groups.yahoo.com/group/python-brasil/

<*> Para sair deste grupo, envie um e-mail para:
    [hidden email]

<*> O uso que você faz do Yahoo! Grupos está sujeito aos:
    http://br.yahoo.com/info/utos.html


Reply | Threaded
Open this post in threaded view
|

Re: Strategy com o quê?

Alexandre Machado
Concordo com o Rodrigo... um decorator parece ser a melhor forma de
combinar estes comportamentos

Alexandre

Em Ter, 2011-07-12 às 08:36 -0300, Rodrigo Ferreira de Souza escreveu:

> Para combinar vrias opes de desconto, sugiro dar uma lida no padro
> decorator, com ele voce consegue esse comportamento.
>
> Atenciosamente,
> Rodrigo
>
> 2011/7/12 <[hidden email]>
>
> > **
> >
> >
> > [first post here]
> >
> > Pessoal, estou tentando aqui com a galera do python (que estou
> > estudando h alguns dias).
> > A tendncia  ter mais entendidos de OOP aqui do que no outro grupo
> > onde postei essa dvida.
> > Se algum puder ajudar agradeo muito:
> >
> > Tenho um sistema de pagamentos.
> > Nele preciso criar um esquema com estratgias de desconto.
> > Ento resolvi usar o Strategy assim:
> >
> > <<interface>> (ou abstract)
> > IEstrategiaDeDesconto
> > public getTotalDoDesconto(Venda v)
> >
> > Agora as implementaes:
> >
> > class DescontoPorTotalMaiorQueX
> >
> > class DescontoPorCupom
> >
> > class DescontoPorFormaDePagto
> >
> > Como a Venda contm informaes sobre os produtos, seus valores e etc
> > isso funciona bem. Quando quero o total apenas chamo o mtodo
> > getTotalDoDesconto() da implementao de desconto que
> > estiver em uso.
> >
> > A questo :
> > Como eu poderia COMBINAR mltiplas formas de desconto simultaneamente?
> > O modelo atual apenas
> > permite usar uma por vez.
> >
> > Seria melhor criar um array dentro de Venda contendo as implementaes
> > de desconto em uso e depois loopar para somar o total dos descontos pra
> > ento
> > aplicar ao total do pagamento?
> >
> > Ou h algum jeito melhor de fazer isso (com menos acoplamento) talvez
> > usando um Decorator ou outro padro de projeto? Qual outro? Como
> > seria?
> >
> > Algum j deve ter passado por isso.
> > Valeu pessoal.
> >  
> >
>
>
> [As partes desta mensagem que no continham texto foram removidas]
>
>
>
> ------------------------------------
>
> Python-Brasil
> http://www.python.org.br/wiki/AntesDePerguntar
> Links do Yahoo! Grupos
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Strategy com o quê?

Magno Junior
In reply to this post by sidtj
Em 12 de julho de 2011 01:07, <[hidden email]> escreveu:

> **
>
>
> [first post here]
>
> Pessoal, estou tentando aqui com a galera do python (que estou
> estudando há alguns dias).
> A tendência é ter mais entendidos de OOP aqui do que no outro grupo
> onde postei essa dúvida.
> Se alguém puder ajudar agradeço muito:
>
> Tenho um sistema de pagamentos.
> Nele preciso criar um esquema com estratégias de desconto.
> Então resolvi usar o Strategy assim:
>
> <<interface>> (ou abstract)
> IEstrategiaDeDesconto
> public getTotalDoDesconto(Venda v)
>
> Agora as implementações:
>
> class DescontoPorTotalMaiorQueX
>
> class DescontoPorCupom
>
> class DescontoPorFormaDePagto
>
> Como a Venda contém informações sobre os produtos, seus valores e etc
> isso funciona bem. Quando quero o total apenas chamo o método
> getTotalDoDesconto() da implementação de desconto que
> estiver em uso.
>
> Acho que em python não precisa fazer nada pra sempre utilizar o
getTotalDesconto (Esse nome ficou meio feio, não?) da implementação que
estiver em uso.
Ele sempre vai fazer isso, independente de existir ou não interface definida
para o objeto em questão.

> A questão é:
> Como eu poderia COMBINAR múltiplas formas de desconto simultaneamente?
> O modelo atual apenas
> permite usar uma por vez.
>
> Seria melhor criar um array dentro de Venda contendo as implementações
> de desconto em uso e depois loopar para somar o total dos descontos pra
> então
> aplicar ao total do pagamento?
>
> Ou há algum jeito melhor de fazer isso (com menos acoplamento) talvez
> usando um Decorator ou outro padrão de projeto? Qual outro? Como
> seria?
>
> Alguém já deve ter passado por isso.
> Valeu pessoal.
>  
>


[As partes desta mensagem que não continham texto foram removidas]



------------------------------------

Python-Brasil
http://www.python.org.br/wiki/AntesDePerguntar
Links do Yahoo! Grupos

<*> Para visitar o site do seu grupo na web, acesse:
    http://br.groups.yahoo.com/group/python-brasil/

<*> Para sair deste grupo, envie um e-mail para:
    [hidden email]

<*> O uso que você faz do Yahoo! Grupos está sujeito aos:
    http://br.yahoo.com/info/utos.html


Reply | Threaded
Open this post in threaded view
|

Re: Strategy com o quê?

sidtj
Então parece que eu não estava tão longe quando mencionei o decorator.
Obrigado pessoal.

Agora uma coisa que não entendi:

O strategy permite que eu crie certas restrições, na realidade, que eu
crie uma assinatura (via interface ou abstract) o que me garantirá que
toda a classe *saiba* como me retornar o valor de desconto que ela
implementa.

Se no python eu "não preciso do strategy", como eu garanto que sempre
a classe que foi chamada terá a implementação do método que calcula o
desconto? Afinal, a ideia é essa. Futuramente se eu precisar de um
novo tipo de desconto, basta criar uma nova implementação da
interface/abstract existente e não precisarei mudar nenhum código.
Como pode o python "não precisar" do strategy?

???



2011/7/12 Magno Junior <[hidden email]>:

> Em 12 de julho de 2011 01:07, <[hidden email]> escreveu:
>
>> **
>>
>>
>> [first post here]
>>
>> Pessoal, estou tentando aqui com a galera do python (que estou
>> estudando há alguns dias).
>> A tendência é ter mais entendidos de OOP aqui do que no outro grupo
>> onde postei essa dúvida.
>> Se alguém puder ajudar agradeço muito:
>>
>> Tenho um sistema de pagamentos.
>> Nele preciso criar um esquema com estratégias de desconto.
>> Então resolvi usar o Strategy assim:
>>
>> <<interface>> (ou abstract)
>> IEstrategiaDeDesconto
>> public getTotalDoDesconto(Venda v)
>>
>> Agora as implementações:
>>
>> class DescontoPorTotalMaiorQueX
>>
>> class DescontoPorCupom
>>
>> class DescontoPorFormaDePagto
>>
>> Como a Venda contém informações sobre os produtos, seus valores e etc
>> isso funciona bem. Quando quero o total apenas chamo o método
>> getTotalDoDesconto() da implementação de desconto que
>> estiver em uso.
>>
>> Acho que em python não precisa fazer nada pra sempre utilizar o
> getTotalDesconto (Esse nome ficou meio feio, não?) da implementação que
> estiver em uso.
> Ele sempre vai fazer isso, independente de existir ou não interface definida
> para o objeto em questão.
>
>> A questão é:
>> Como eu poderia COMBINAR múltiplas formas de desconto simultaneamente?
>> O modelo atual apenas
>> permite usar uma por vez.
>>
>> Seria melhor criar um array dentro de Venda contendo as implementações
>> de desconto em uso e depois loopar para somar o total dos descontos pra
>> então
>> aplicar ao total do pagamento?
>>
>> Ou há algum jeito melhor de fazer isso (com menos acoplamento) talvez
>> usando um Decorator ou outro padrão de projeto? Qual outro? Como
>> seria?
>>
>> Alguém já deve ter passado por isso.
>> Valeu pessoal.
>>
>>
>
>
> [As partes desta mensagem que não continham texto foram removidas]
>
>
>
> ------------------------------------
>
> Python-Brasil
> http://www.python.org.br/wiki/AntesDePerguntar
> Links do Yahoo! Grupos
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Strategy com o quê?

Magno Junior
In reply to this post by Rodrigo Ferreira de Souza-2
Em 12 de julho de 2011 08:33, Rodrigo Ferreira de Souza <
[hidden email]> escreveu:

> No python todas as funções são objetos, o que significa que voce não
> precisa
> criar o padrão strategy.. só passar a função como parâmetro como se fosse
>

Um outro ponto que colocam muito é que padrões de projeto devem emergir
naturalmente do modelo, e não construir o modelo com base nos padrões de
projeto.

Por exemplo, acho que a sugestão da Venda com Desconto ( acho que isso seria
o padrão decorator), pode até ser interssante, mas somente com as
informações que possuimos não da pra dizer até que ponto é realmente
necessária.





> uma variável qualquer.
>
> 2011/7/12 <[hidden email]>
>
> > **
> >
> >
> > [first post here]
> >
> > Pessoal, estou tentando aqui com a galera do python (que estou
> > estudando há alguns dias).
> > A tendência é ter mais entendidos de OOP aqui do que no outro grupo
> > onde postei essa dúvida.
> > Se alguém puder ajudar agradeço muito:
> >
> > Tenho um sistema de pagamentos.
> > Nele preciso criar um esquema com estratégias de desconto.
> > Então resolvi usar o Strategy assim:
> >
> > <<interface>> (ou abstract)
> > IEstrategiaDeDesconto
> > public getTotalDoDesconto(Venda v)
> >
> > Agora as implementações:
> >
> > class DescontoPorTotalMaiorQueX
> >
> > class DescontoPorCupom
> >
> > class DescontoPorFormaDePagto
> >
> > Como a Venda contém informações sobre os produtos, seus valores e etc
> > isso funciona bem. Quando quero o total apenas chamo o método
> > getTotalDoDesconto() da implementação de desconto que
> > estiver em uso.
> >
> > A questão é:
> > Como eu poderia COMBINAR múltiplas formas de desconto simultaneamente?
> > O modelo atual apenas
> > permite usar uma por vez.
> >
> > Seria melhor criar um array dentro de Venda contendo as implementações
> > de desconto em uso e depois loopar para somar o total dos descontos pra
> > então
> > aplicar ao total do pagamento?
> >
> > Ou há algum jeito melhor de fazer isso (com menos acoplamento) talvez
> > usando um Decorator ou outro padrão de projeto? Qual outro? Como
> > seria?
> >
> > Alguém já deve ter passado por isso.
> > Valeu pessoal.
> >
> >
>
>
> [As partes desta mensagem que não continham texto foram removidas]
>
>
>
> ------------------------------------
>
> Python-Brasil
> http://www.python.org.br/wiki/AntesDePerguntar
> Links do Yahoo! Grupos
>
>
>


[As partes desta mensagem que não continham texto foram removidas]

Reply | Threaded
Open this post in threaded view
|

Re: Strategy com o quê?

sidtj
Magno, obrigado.
Mas a quanto a ser necessária, é.

Já o seu outro argumento eu discordo. Qual a vantagem que eu tenho em
esperar surgir a necessidade de um design pattern, ou seja, surgir um
problema pra só então eu utilizá-lo? Se o problema já é conhecido e já tem
solução conhecida e provada (o design pattern) então por que esperar o
problema acontecer no sistema?

Inclusive, este do strategy é um caso *muito* comum. Sem usá-lo posso ficar
em apuros depois se eu precisar acrescentar novas formas de desconto. Vai
tomar muitoo tempo e ainda vai causar repetição desnecessária.

Mas a minha outra dúvida do e-mail anterior ainda está aberta a quem puder
esclarecer (agradeço desde já).

Obrigado.

2011/7/12 Magno Junior <[hidden email]>

> **
>
>
> Em 12 de julho de 2011 08:33, Rodrigo Ferreira de Souza <
> [hidden email]> escreveu:
>
>
> > No python todas as funções são objetos, o que significa que voce não
> > precisa
> > criar o padrão strategy.. só passar a função como parâmetro como se fosse
> >
>
> Um outro ponto que colocam muito é que padrões de projeto devem emergir
> naturalmente do modelo, e não construir o modelo com base nos padrões de
> projeto.
>
> Por exemplo, acho que a sugestão da Venda com Desconto ( acho que isso
> seria
> o padrão decorator), pode até ser interssante, mas somente com as
> informações que possuimos não da pra dizer até que ponto é realmente
> necessária.
>
>
> > uma variável qualquer.
> >
> > 2011/7/12 <[hidden email]>
> >
> > > **
> > >
> > >
> > > [first post here]
> > >
> > > Pessoal, estou tentando aqui com a galera do python (que estou
> > > estudando há alguns dias).
> > > A tendência é ter mais entendidos de OOP aqui do que no outro grupo
> > > onde postei essa dúvida.
> > > Se alguém puder ajudar agradeço muito:
> > >
> > > Tenho um sistema de pagamentos.
> > > Nele preciso criar um esquema com estratégias de desconto.
> > > Então resolvi usar o Strategy assim:
> > >
> > > <<interface>> (ou abstract)
> > > IEstrategiaDeDesconto
> > > public getTotalDoDesconto(Venda v)
> > >
> > > Agora as implementações:
> > >
> > > class DescontoPorTotalMaiorQueX
> > >
> > > class DescontoPorCupom
> > >
> > > class DescontoPorFormaDePagto
> > >
> > > Como a Venda contém informações sobre os produtos, seus valores e etc
> > > isso funciona bem. Quando quero o total apenas chamo o método
> > > getTotalDoDesconto() da implementação de desconto que
> > > estiver em uso.
> > >
> > > A questão é:
> > > Como eu poderia COMBINAR múltiplas formas de desconto simultaneamente?
> > > O modelo atual apenas
> > > permite usar uma por vez.
> > >
> > > Seria melhor criar um array dentro de Venda contendo as implementações
> > > de desconto em uso e depois loopar para somar o total dos descontos pra
> > > então
> > > aplicar ao total do pagamento?
> > >
> > > Ou há algum jeito melhor de fazer isso (com menos acoplamento) talvez
> > > usando um Decorator ou outro padrão de projeto? Qual outro? Como
> > > seria?
> > >
> > > Alguém já deve ter passado por isso.
> > > Valeu pessoal.
> > >
> > >
> >
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
> >
> >
> > ------------------------------------
> >
> > Python-Brasil
> > http://www.python.org.br/wiki/AntesDePerguntar
> > Links do Yahoo! Grupos
> >
> >
> >
>
> [As partes desta mensagem que não continham texto foram removidas]
>
>  
>


[As partes desta mensagem que não continham texto foram removidas]



------------------------------------

Python-Brasil
http://www.python.org.br/wiki/AntesDePerguntar
Links do Yahoo! Grupos

<*> Para visitar o site do seu grupo na web, acesse:
    http://br.groups.yahoo.com/group/python-brasil/

<*> Para sair deste grupo, envie um e-mail para:
    [hidden email]

<*> O uso que você faz do Yahoo! Grupos está sujeito aos:
    http://br.yahoo.com/info/utos.html


Reply | Threaded
Open this post in threaded view
|

Re: Strategy com o quê?

Magno Junior
Em 12 de julho de 2011 11:51, <[hidden email]> escreveu:

> Magno, obrigado.
> Mas a quanto a ser necessária, é.
>
> Não entendi.
O que quis dizer é que sempre que voce receber um objeto por parametro e
chamar o metodo getTotalPreco, voce terá uma resposta, independente do que
quer que seja esse objeto. Basta ele ter o método implementado. Não precisa
de uma interface.


Já o seu outro argumento eu discordo. Qual a vantagem que eu tenho em
> esperar surgir a necessidade de um design pattern, ou seja, surgir um
> problema pra só então eu utilizá-lo? Se o problema já é conhecido e já tem
> solução conhecida e provada (o design pattern) então por que esperar o
> problema acontecer no sistema?
>
> Novamente, o que quis dizer foi:
Se existe um problema com solução conhecida, resolve com os padrões já
conhecidos. A questão é: Existe mesmo esse problema?
Nem sempre é necessário eu adicionar complexidade quando ela é desnecessária
somente pelo fato de ser um padrão de projeto.

Por exemplo: Tenho uma classe Pessoa, então para acessar essa classe vou
criar uma interface PessoaFacade para evitar o acoplamento desta classe com
as outras do modelo (???). Isso faz algum sentido? depende muito.




> Inclusive, este do strategy é um caso *muito* comum. Sem usá-lo posso ficar
> em apuros depois se eu precisar acrescentar novas formas de desconto. Vai
> tomar muitoo tempo e ainda vai causar repetição desnecessária.
>
> Mas a minha outra dúvida do e-mail anterior ainda está aberta a quem puder
> esclarecer (agradeço desde já).
>
> Obrigado.
>
> 2011/7/12 Magno Junior <[hidden email]>
>
> > **
> >
> >
> > Em 12 de julho de 2011 08:33, Rodrigo Ferreira de Souza <
> > [hidden email]> escreveu:
> >
> >
> > > No python todas as funções são objetos, o que significa que voce não
> > > precisa
> > > criar o padrão strategy.. só passar a função como parâmetro como se
> fosse
> > >
> >
> > Um outro ponto que colocam muito é que padrões de projeto devem emergir
> > naturalmente do modelo, e não construir o modelo com base nos padrões de
> > projeto.
> >
> > Por exemplo, acho que a sugestão da Venda com Desconto ( acho que isso
> > seria
> > o padrão decorator), pode até ser interssante, mas somente com as
> > informações que possuimos não da pra dizer até que ponto é realmente
> > necessária.
> >
> >
> > > uma variável qualquer.
> > >
> > > 2011/7/12 <[hidden email]>
> > >
> > > > **
> > > >
> > > >
> > > > [first post here]
> > > >
> > > > Pessoal, estou tentando aqui com a galera do python (que estou
> > > > estudando há alguns dias).
> > > > A tendência é ter mais entendidos de OOP aqui do que no outro grupo
> > > > onde postei essa dúvida.
> > > > Se alguém puder ajudar agradeço muito:
> > > >
> > > > Tenho um sistema de pagamentos.
> > > > Nele preciso criar um esquema com estratégias de desconto.
> > > > Então resolvi usar o Strategy assim:
> > > >
> > > > <<interface>> (ou abstract)
> > > > IEstrategiaDeDesconto
> > > > public getTotalDoDesconto(Venda v)
> > > >
> > > > Agora as implementações:
> > > >
> > > > class DescontoPorTotalMaiorQueX
> > > >
> > > > class DescontoPorCupom
> > > >
> > > > class DescontoPorFormaDePagto
> > > >
> > > > Como a Venda contém informações sobre os produtos, seus valores e etc
> > > > isso funciona bem. Quando quero o total apenas chamo o método
> > > > getTotalDoDesconto() da implementação de desconto que
> > > > estiver em uso.
> > > >
> > > > A questão é:
> > > > Como eu poderia COMBINAR múltiplas formas de desconto
> simultaneamente?
> > > > O modelo atual apenas
> > > > permite usar uma por vez.
> > > >
> > > > Seria melhor criar um array dentro de Venda contendo as
> implementações
> > > > de desconto em uso e depois loopar para somar o total dos descontos
> pra
> > > > então
> > > > aplicar ao total do pagamento?
> > > >
> > > > Ou há algum jeito melhor de fazer isso (com menos acoplamento) talvez
> > > > usando um Decorator ou outro padrão de projeto? Qual outro? Como
> > > > seria?
> > > >
> > > > Alguém já deve ter passado por isso.
> > > > Valeu pessoal.
> > > >
> > > >
> > >
> > >
> > > [As partes desta mensagem que não continham texto foram removidas]
> > >
> > >
> > >
> > > ------------------------------------
> > >
> > > Python-Brasil
> > > http://www.python.org.br/wiki/AntesDePerguntar
> > > Links do Yahoo! Grupos
> > >
> > >
> > >
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
> >
> >
>
>
> [As partes desta mensagem que não continham texto foram removidas]
>
>
>
> ------------------------------------
>
> Python-Brasil
> http://www.python.org.br/wiki/AntesDePerguntar
> Links do Yahoo! Grupos
>
>
>


[As partes desta mensagem que não continham texto foram removidas]

Reply | Threaded
Open this post in threaded view
|

Re: Strategy com o quê?

Leonardo Santagada
In reply to this post by sidtj
2011/7/12  <[hidden email]>:
> Magno, obrigado.
> Mas a quanto a ser necessária, é.

Não não é, metade dos design patterns do livro da gangue dos quartro
não precisa ser implementado em python, porque a linguagem faz com que
eles sejam transparentes. Um deles é esse caso de estrategy onde usar
um callable é suficiente. Outro é aplicar vários descontos, ou tu
chama cada um em uma lista de descontos, ou faz encadeamento de
chamadas (se as funções retornarem a venda toda, ou puderem receber
como entrada só um valor).


--
Leonardo Santagada
Reply | Threaded
Open this post in threaded view
|

Re: Strategy com o quê?

Magno Junior
Em 12 de julho de 2011 14:20, Leonardo Santagada <[hidden email]>escreveu:

> **
>
>
> 2011/7/12 <[hidden email]>:
>
> > Magno, obrigado.
> > Mas a quanto a ser necessária, é.
>
> Não não é, metade dos design patterns do livro da gangue dos quartro
> não precisa ser implementado em python, porque a linguagem faz com que
> eles sejam transparentes. Um deles é esse caso de estrategy onde usar
> um callable é suficiente. Outro é aplicar vários descontos, ou tu
> chama cada um em uma lista de descontos, ou faz encadeamento de
> chamadas (se as funções retornarem a venda toda, ou puderem receber
> como entrada só um valor).
>
> --
> Leonardo Santagada
>
>  __.
>
Isso é verdade.
O próprio padrão Facade que citei no email anterior é praticamente
desnecessário em python.



> _,_.___
>
> <[hidden email]?subject=Res%3A%20Re%3A%20%5Bpython-brasil%5D%20Strategy%20com%20o%20qu%C3%AA%3F>| através
> de email<[hidden email]?subject=Res%3A%20Re%3A%20%5Bpython-brasil%5D%20Strategy%20com%20o%20qu%C3%AA%3F>| Responder
> através da web<http://br.groups.yahoo.com/group/python-brasil/post;_ylc=X3oDMTJydXJoZTl0BF9TAzk3NDkwNDM3BGdycElkAzEwNDUyNDM4BGdycHNwSWQDMjEzNzExMTI1OQRtc2dJZAM1MTkzMQRzZWMDZnRyBHNsawNycGx5BHN0aW1lAzEzMTA0OTEyNTU-?act=reply&messageNum=51931>| Adicionar
> um novo tópico<http://br.groups.yahoo.com/group/python-brasil/post;_ylc=X3oDMTJmb3Y5dGQ5BF9TAzk3NDkwNDM3BGdycElkAzEwNDUyNDM4BGdycHNwSWQDMjEzNzExMTI1OQRzZWMDZnRyBHNsawNudHBjBHN0aW1lAzEzMTA0OTEyNTU->
> Mensagens neste tópico<http://br.groups.yahoo.com/group/python-brasil/message/51906;_ylc=X3oDMTM3OWthbzc3BF9TAzk3NDkwNDM3BGdycElkAzEwNDUyNDM4BGdycHNwSWQDMjEzNzExMTI1OQRtc2dJZAM1MTkzMQRzZWMDZnRyBHNsawN2dHBjBHN0aW1lAzEzMTA0OTEyNTUEdHBjSWQDNTE5MDY->(
> 9)
>  Atividade nos últimos dias:
>
>    - Novos usuários<http://br.groups.yahoo.com/group/python-brasil/members;_ylc=X3oDMTJnYTlyNHVnBF9TAzk3NDkwNDM3BGdycElkAzEwNDUyNDM4BGdycHNwSWQDMjEzNzExMTI1OQRzZWMDdnRsBHNsawN2bWJycwRzdGltZQMxMzEwNDkxMjU1?o=6>
>    13
>
>  Visite seu Grupo<http://br.groups.yahoo.com/group/python-brasil;_ylc=X3oDMTJmdGkyczgzBF9TAzk3NDkwNDM3BGdycElkAzEwNDUyNDM4BGdycHNwSWQDMjEzNzExMTI1OQRzZWMDdnRsBHNsawN2Z2hwBHN0aW1lAzEzMTA0OTEyNTU->
>  Python-Brasil
> http://www.python.org.br/wiki/AntesDePerguntar
>  [image: Yahoo! Grupos]<http://br.groups.yahoo.com/;_ylc=X3oDMTJlc2pzYXE4BF9TAzk3NDkwNDM3BGdycElkAzEwNDUyNDM4BGdycHNwSWQDMjEzNzExMTI1OQRzZWMDZnRyBHNsawNnZnAEc3RpbWUDMTMxMDQ5MTI1NQ-->
> Trocar para: Só Texto<[hidden email]?subject=Mudar+Formato+de+Envio:+Tradicional>,
> Resenha Diária<[hidden email]?subject=Envio+de+email:+Resenha>• Sair
> do grupo<[hidden email]?subject=Sair+do+grupo>• Termos
> de uso <http://br.yahoo.com/info/utos.html>
>    .
>
>
>


[As partes desta mensagem que não continham texto foram removidas]



------------------------------------

Python-Brasil
http://www.python.org.br/wiki/AntesDePerguntar
Links do Yahoo! Grupos

<*> Para visitar o site do seu grupo na web, acesse:
    http://br.groups.yahoo.com/group/python-brasil/

<*> Para sair deste grupo, envie um e-mail para:
    [hidden email]

<*> O uso que você faz do Yahoo! Grupos está sujeito aos:
    http://br.yahoo.com/info/utos.html


Reply | Threaded
Open this post in threaded view
|

Re: Strategy com o quê?

sidtj
In reply to this post by Magno Junior
> Magno, obrigado.
> Mas a quanto a ser necessária, é.
>
> Não entendi.
O que quis dizer é que sempre que voce receber um objeto por parametro e
chamar o metodo getTotalPreco, voce terá uma resposta, independente do que
quer que seja esse objeto. Basta ele ter o método implementado. Não precisa
de uma interface.

Bom, se eu for pensar assim então eu tenho que pensar que *nunca* vou
precisar de uma interface porque no final das contas basta haver a
implementação e "isso é o que importa".


Já o seu outro argumento eu discordo. Qual a vantagem que eu tenho em
> esperar surgir a necessidade de um design pattern, ou seja, surgir um
> problema pra só então eu utilizá-lo? Se o problema já é conhecido e já tem
> solução conhecida e provada (o design pattern) então por que esperar o
> problema acontecer no sistema?
>
> Novamente, o que quis dizer foi:
Se existe um problema com solução conhecida, resolve com os padrões já
conhecidos. A questão é: Existe mesmo esse problema?

A resposta a questão é: sim. Existe um problema.
E sim, existe a solução. E sim, ela está documentada.

Nem sempre é necessário eu adicionar complexidade quando ela é desnecessária
somente pelo fato de ser um padrão de projeto.

Esse definitivamente não é o caso. Isso é um mito na cabeça das pessoas de
que,
em geral, se você usa um design pattern você está "adicionando
complexidade".
Muito pelo contrário, estou FUGINDO dela. Complexidade não se mede por
quanto
código eu tenho mas sim por quanto código eu TEREI QUE MUDAR numa futura
manutenção.
É verdade que alguns exageram. Mas este não é o caso.
Veja a definição do Strategy (wikipedia):

Definir uma família de algoritmos <http://pt.wikipedia.org/wiki/Algoritmo> e
encapsular cada algoritmo como uma
classe<http://pt.wikipedia.org/wiki/Classe_%28programa%C3%A7%C3%A3o%29>,
permitindo assim que elas possam ter trocados entre si. Este padrão permite
que o algoritmo possa variar independentemente dos clientes que o utilizam.

Utilizar o padrão Strategy quando:

•um objecto deve ser parametrizado com um de vários algoritmos, os quais
podem ser encapsulados e representados* por uma única
interface<http://pt.wikipedia.org/wiki/Interface>
.*


Por exemplo: Tenho uma classe Pessoa, então para acessar essa classe vou
criar uma interface PessoaFacade para evitar o acoplamento desta classe com
as outras do modelo (???). Isso faz algum sentido? depende muito.

Desculpe mas isso não tem nada a ver com o problema proposto.
**
E antes que isso vire um flame, não precisa responder se não souber.
Pois agradeço sinceramente a contribuição até aqui.


2011/7/12 Magno Junior <[hidden email]>

> **
>
>
> Em 12 de julho de 2011 11:51, <[hidden email]> escreveu:
>
>
> > Magno, obrigado.
> > Mas a quanto a ser necessária, é.
> >
> > Não entendi.
> O que quis dizer é que sempre que voce receber um objeto por parametro e
> chamar o metodo getTotalPreco, voce terá uma resposta, independente do que
> quer que seja esse objeto. Basta ele ter o método implementado. Não precisa
> de uma interface.
>
>
> Já o seu outro argumento eu discordo. Qual a vantagem que eu tenho em
> > esperar surgir a necessidade de um design pattern, ou seja, surgir um
> > problema pra só então eu utilizá-lo? Se o problema já é conhecido e já
> tem
> > solução conhecida e provada (o design pattern) então por que esperar o
> > problema acontecer no sistema?
> >
> > Novamente, o que quis dizer foi:
> Se existe um problema com solução conhecida, resolve com os padrões já
> conhecidos. A questão é: Existe mesmo esse problema?
> Nem sempre é necessário eu adicionar complexidade quando ela é
> desnecessária
> somente pelo fato de ser um padrão de projeto.
>
> Por exemplo: Tenho uma classe Pessoa, então para acessar essa classe vou
> criar uma interface PessoaFacade para evitar o acoplamento desta classe com
> as outras do modelo (???). Isso faz algum sentido? depende muito.
>
>
> > Inclusive, este do strategy é um caso *muito* comum. Sem usá-lo posso
> ficar
> > em apuros depois se eu precisar acrescentar novas formas de desconto. Vai
> > tomar muitoo tempo e ainda vai causar repetição desnecessária.
> >
> > Mas a minha outra dúvida do e-mail anterior ainda está aberta a quem
> puder
> > esclarecer (agradeço desde já).
> >
> > Obrigado.
> >
> > 2011/7/12 Magno Junior <[hidden email]>
> >
> > > **
> > >
> > >
> > > Em 12 de julho de 2011 08:33, Rodrigo Ferreira de Souza <
> > > [hidden email]> escreveu:
> > >
> > >
> > > > No python todas as funções são objetos, o que significa que voce não
> > > > precisa
> > > > criar o padrão strategy.. só passar a função como parâmetro como se
> > fosse
> > > >
> > >
> > > Um outro ponto que colocam muito é que padrões de projeto devem emergir
> > > naturalmente do modelo, e não construir o modelo com base nos padrões
> de
> > > projeto.
> > >
> > > Por exemplo, acho que a sugestão da Venda com Desconto ( acho que isso
> > > seria
> > > o padrão decorator), pode até ser interssante, mas somente com as
> > > informações que possuimos não da pra dizer até que ponto é realmente
> > > necessária.
> > >
> > >
> > > > uma variável qualquer.
> > > >
> > > > 2011/7/12 <[hidden email]>
> > > >
> > > > > **
> > > > >
> > > > >
> > > > > [first post here]
> > > > >
> > > > > Pessoal, estou tentando aqui com a galera do python (que estou
> > > > > estudando há alguns dias).
> > > > > A tendência é ter mais entendidos de OOP aqui do que no outro grupo
> > > > > onde postei essa dúvida.
> > > > > Se alguém puder ajudar agradeço muito:
> > > > >
> > > > > Tenho um sistema de pagamentos.
> > > > > Nele preciso criar um esquema com estratégias de desconto.
> > > > > Então resolvi usar o Strategy assim:
> > > > >
> > > > > <<interface>> (ou abstract)
> > > > > IEstrategiaDeDesconto
> > > > > public getTotalDoDesconto(Venda v)
> > > > >
> > > > > Agora as implementações:
> > > > >
> > > > > class DescontoPorTotalMaiorQueX
> > > > >
> > > > > class DescontoPorCupom
> > > > >
> > > > > class DescontoPorFormaDePagto
> > > > >
> > > > > Como a Venda contém informações sobre os produtos, seus valores e
> etc
> > > > > isso funciona bem. Quando quero o total apenas chamo o método
> > > > > getTotalDoDesconto() da implementação de desconto que
> > > > > estiver em uso.
> > > > >
> > > > > A questão é:
> > > > > Como eu poderia COMBINAR múltiplas formas de desconto
> > simultaneamente?
> > > > > O modelo atual apenas
> > > > > permite usar uma por vez.
> > > > >
> > > > > Seria melhor criar um array dentro de Venda contendo as
> > implementações
> > > > > de desconto em uso e depois loopar para somar o total dos descontos
> > pra
> > > > > então
> > > > > aplicar ao total do pagamento?
> > > > >
> > > > > Ou há algum jeito melhor de fazer isso (com menos acoplamento)
> talvez
> > > > > usando um Decorator ou outro padrão de projeto? Qual outro? Como
> > > > > seria?
> > > > >
> > > > > Alguém já deve ter passado por isso.
> > > > > Valeu pessoal.
> > > > >
> > > > >
> > > >
> > > >
> > > > [As partes desta mensagem que não continham texto foram removidas]
> > > >
> > > >
> > > >
> > > > ------------------------------------
> > > >
> > > > Python-Brasil
> > > > http://www.python.org.br/wiki/AntesDePerguntar
> > > > Links do Yahoo! Grupos
> > > >
> > > >
> > > >
> > >
> > > [As partes desta mensagem que não continham texto foram removidas]
> > >
> > >
> > >
> >
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
> >
> >
> > ------------------------------------
> >
> > Python-Brasil
> > http://www.python.org.br/wiki/AntesDePerguntar
> > Links do Yahoo! Grupos
> >
> >
> >
>
> [As partes desta mensagem que não continham texto foram removidas]
>
>  
>


[As partes desta mensagem que não continham texto foram removidas]



------------------------------------

Python-Brasil
http://www.python.org.br/wiki/AntesDePerguntar
Links do Yahoo! Grupos

<*> Para visitar o site do seu grupo na web, acesse:
    http://br.groups.yahoo.com/group/python-brasil/

<*> Para sair deste grupo, envie um e-mail para:
    [hidden email]

<*> O uso que você faz do Yahoo! Grupos está sujeito aos:
    http://br.yahoo.com/info/utos.html


Reply | Threaded
Open this post in threaded view
|

Re: Strategy com o quê?

sidtj
In reply to this post by Leonardo Santagada
2011/7/12 Leonardo Santagada <[hidden email]>

> **
>
>
> 2011/7/12 <[hidden email]>:
>
> > Magno, obrigado.
> > Mas a quanto a ser necessária, é.
>
> Não não é, metade dos design patterns do livro da gangue dos quartro
> não precisa ser implementado em python, porque a linguagem faz com que
> eles sejam transparentes. Um deles é esse caso de estrategy onde usar
> um callable é suficiente. Outro é aplicar vários descontos, ou tu
> chama cada um em uma lista de descontos, ou faz encadeamento de
> chamadas (se as funções retornarem a venda toda, ou puderem receber
> como entrada só um valor).
>

Ainda não cheguei nessa parte de "callabe" (em python) pra ter condições de
entender sua mensagem
pois ainda estou estudando essa linguagem.

Mas até onde sei um design pattern não tem nada a ver com a linguagem. Desde
que ela seja OO
o design pattern envolve um conceito abstrato de resolução de um problema e
ele pode ser aplicado
em qualquer linguagem (OO).

Mas talvez você esteja certo pois não conheço o callabe, apenas acho muito
estranha essa hipótese.

Obrigado.


> --
> Leonardo Santagada
>
>  
>


[As partes desta mensagem que não continham texto foram removidas]



------------------------------------

Python-Brasil
http://www.python.org.br/wiki/AntesDePerguntar
Links do Yahoo! Grupos

<*> Para visitar o site do seu grupo na web, acesse:
    http://br.groups.yahoo.com/group/python-brasil/

<*> Para sair deste grupo, envie um e-mail para:
    [hidden email]

<*> O uso que você faz do Yahoo! Grupos está sujeito aos:
    http://br.yahoo.com/info/utos.html


Reply | Threaded
Open this post in threaded view
|

Re: Strategy com o quê?

Luciano Ramalho
In reply to this post by Rodrigo Ferreira de Souza-2
2011/7/12 Rodrigo Ferreira de Souza <[hidden email]>:
> No python todas as funções são objetos, o que significa que voce não precisa
> criar o padrão strategy.. só passar a função como parâmetro como se fosse
> uma variável qualquer.

É isso aí, mandou muito bem, Rodrigo.

A maioria dos padrões de projeto da categoria "comportamento" no livro
da GoF são tão simplificados em Python que nem vale a pena olhar para
sua implementação original.

É muito importante lembrar que os padrões de projeto dependem muito da
linguagem, dependendo da linguagem de implementação eles perdem o
sentido porque se tornam desnecessários.

No livro original da Ganque dos 4 (GoF) os exemplos são em C++, e Java
foi fortemente inspirada em C++, portanto os padrões se aplicam em
Java também. Existem outros livros revendo os padrões de projeto
originais no contexto de Smalltalk e Ruby que se aproximam mais do que
funcionaria bem em Python. Porém tanto Smalltalk quanto Ruby têm
blocos com closures, que Python substitui pela passagem de funções
como argumentos, e isso deve mudar um tanto a construção de alguns
padrões.

O Bruce Eckel, autor do Thinking in Java, tem um esboço de livro sobre
padrões de projeto que tenta ser aplicável em Python também (ele deu
um workshop sobre isso na Globalcode em São Paulo antes da PythonBrasl
2008 que foi no Rio).

--
Luciano Ramalho
programador repentista || stand-up programmer
Twitter: @luciano
Reply | Threaded
Open this post in threaded view
|

Re: Strategy com o quê?

Luciano Ramalho
2011/7/13 Luciano Ramalho <[hidden email]>:
> O Bruce Eckel, autor do Thinking in Java, tem um esboço de livro sobre
> padrões de projeto que tenta ser aplicável em Python também (ele deu
> um workshop sobre isso na Globalcode em São Paulo antes da PythonBrasl
> 2008 que foi no Rio).

Talvez o livro seja este, mas não tive tempo de conferir:

http://www.mindviewinc.com/Books/Python3Patterns/Index.php


--
Luciano Ramalho
programador repentista || stand-up programmer
Twitter: @luciano
Reply | Threaded
Open this post in threaded view
|

Re: Strategy com o quê?

Magno Junior
In reply to this post by sidtj
Em 12 de julho de 2011 23:57, <[hidden email]> escreveu:

> > Magno, obrigado.
> > Mas a quanto a ser necessária, é.
> >
> > Não entendi.
> O que quis dizer é que sempre que voce receber um objeto por parametro e
> chamar o metodo getTotalPreco, voce terá uma resposta, independente do que
> quer que seja esse objeto. Basta ele ter o método implementado. Não precisa
> de uma interface.
>
> Bom, se eu for pensar assim então eu tenho que pensar que *nunca* vou
> precisar de uma interface porque no final das contas basta haver a
> implementação e "isso é o que importa".
>
> Em python voce NUNCA irá precisar de uma interface. ( Somos muito grato por
isso).


>
> Já o seu outro argumento eu discordo. Qual a vantagem que eu tenho em
> > esperar surgir a necessidade de um design pattern, ou seja, surgir um
> > problema pra só então eu utilizá-lo? Se o problema já é conhecido e já
> tem
> > solução conhecida e provada (o design pattern) então por que esperar o
> > problema acontecer no sistema?
> >
> > Novamente, o que quis dizer foi:
> Se existe um problema com solução conhecida, resolve com os padrões já
> conhecidos. A questão é: Existe mesmo esse problema?
>
> A resposta a questão é: sim. Existe um problema.
> E sim, existe a solução. E sim, ela está documentada.
>
> Nem sempre é necessário eu adicionar complexidade quando ela é
> desnecessária
> somente pelo fato de ser um padrão de projeto.
>
> Esse definitivamente não é o caso. Isso é um mito na cabeça das pessoas de
> que,
> em geral, se você usa um design pattern você está "adicionando
> complexidade".
> Muito pelo contrário, estou FUGINDO dela. Complexidade não se mede por
> quanto
> código eu tenho mas sim por quanto código eu TEREI QUE MUDAR numa futura
> manutenção.
>

Essa é a parte legal. Voce não terá que alterar nenhuma linha de código.


> É verdade que alguns exageram. Mas este não é o caso.
> Veja a definição do Strategy (wikipedia):
>
> Definir uma família de algoritmos <http://pt.wikipedia.org/wiki/Algoritmo>
> e
> encapsular cada algoritmo como uma
> classe<http://pt.wikipedia.org/wiki/Classe_%28programa%C3%A7%C3%A3o%29>,
> permitindo assim que elas possam ter trocados entre si. Este padrão permite
> que o algoritmo possa variar independentemente dos clientes que o utilizam.
>
> Utilizar o padrão Strategy quando:
>
> •um objecto deve ser parametrizado com um de vários algoritmos, os quais
> podem ser encapsulados e representados* por uma única
> interface<http://pt.wikipedia.org/wiki/Interface>
> .*
>
>
> Por exemplo: Tenho uma classe Pessoa, então para acessar essa classe vou
> criar uma interface PessoaFacade para evitar o acoplamento desta classe com
> as outras do modelo (???). Isso faz algum sentido? depende muito.
>
> Desculpe mas isso não tem nada a ver com o problema proposto.
> **
> E antes que isso vire um flame, não precisa responder se não souber.
> Pois agradeço sinceramente a contribuição até aqui.
>
>
> 2011/7/12 Magno Junior <[hidden email]>
>
> > **
> >
> >
> > Em 12 de julho de 2011 11:51, <[hidden email]> escreveu:
> >
> >
> > > Magno, obrigado.
> > > Mas a quanto a ser necessária, é.
> > >
> > > Não entendi.
> > O que quis dizer é que sempre que voce receber um objeto por parametro e
> > chamar o metodo getTotalPreco, voce terá uma resposta, independente do
> que
> > quer que seja esse objeto. Basta ele ter o método implementado. Não
> precisa
> > de uma interface.
> >
> >
> > Já o seu outro argumento eu discordo. Qual a vantagem que eu tenho em
> > > esperar surgir a necessidade de um design pattern, ou seja, surgir um
> > > problema pra só então eu utilizá-lo? Se o problema já é conhecido e já
> > tem
> > > solução conhecida e provada (o design pattern) então por que esperar o
> > > problema acontecer no sistema?
> > >
> > > Novamente, o que quis dizer foi:
> > Se existe um problema com solução conhecida, resolve com os padrões já
> > conhecidos. A questão é: Existe mesmo esse problema?
> > Nem sempre é necessário eu adicionar complexidade quando ela é
> > desnecessária
> > somente pelo fato de ser um padrão de projeto.
> >
> > Por exemplo: Tenho uma classe Pessoa, então para acessar essa classe vou
> > criar uma interface PessoaFacade para evitar o acoplamento desta classe
> com
> > as outras do modelo (???). Isso faz algum sentido? depende muito.
> >
> >
> > > Inclusive, este do strategy é um caso *muito* comum. Sem usá-lo posso
> > ficar
> > > em apuros depois se eu precisar acrescentar novas formas de desconto.
> Vai
> > > tomar muitoo tempo e ainda vai causar repetição desnecessária.
> > >
> > > Mas a minha outra dúvida do e-mail anterior ainda está aberta a quem
> > puder
> > > esclarecer (agradeço desde já).
> > >
> > > Obrigado.
> > >
> > > 2011/7/12 Magno Junior <[hidden email]>
> > >
> > > > **
> > > >
> > > >
> > > > Em 12 de julho de 2011 08:33, Rodrigo Ferreira de Souza <
> > > > [hidden email]> escreveu:
> > > >
> > > >
> > > > > No python todas as funções são objetos, o que significa que voce
> não
> > > > > precisa
> > > > > criar o padrão strategy.. só passar a função como parâmetro como se
> > > fosse
> > > > >
> > > >
> > > > Um outro ponto que colocam muito é que padrões de projeto devem
> emergir
> > > > naturalmente do modelo, e não construir o modelo com base nos padrões
> > de
> > > > projeto.
> > > >
> > > > Por exemplo, acho que a sugestão da Venda com Desconto ( acho que
> isso
> > > > seria
> > > > o padrão decorator), pode até ser interssante, mas somente com as
> > > > informações que possuimos não da pra dizer até que ponto é realmente
> > > > necessária.
> > > >
> > > >
> > > > > uma variável qualquer.
> > > > >
> > > > > 2011/7/12 <[hidden email]>
> > > > >
> > > > > > **
> > > > > >
> > > > > >
> > > > > > [first post here]
> > > > > >
> > > > > > Pessoal, estou tentando aqui com a galera do python (que estou
> > > > > > estudando há alguns dias).
> > > > > > A tendência é ter mais entendidos de OOP aqui do que no outro
> grupo
> > > > > > onde postei essa dúvida.
> > > > > > Se alguém puder ajudar agradeço muito:
> > > > > >
> > > > > > Tenho um sistema de pagamentos.
> > > > > > Nele preciso criar um esquema com estratégias de desconto.
> > > > > > Então resolvi usar o Strategy assim:
> > > > > >
> > > > > > <<interface>> (ou abstract)
> > > > > > IEstrategiaDeDesconto
> > > > > > public getTotalDoDesconto(Venda v)
> > > > > >
> > > > > > Agora as implementações:
> > > > > >
> > > > > > class DescontoPorTotalMaiorQueX
> > > > > >
> > > > > > class DescontoPorCupom
> > > > > >
> > > > > > class DescontoPorFormaDePagto
> > > > > >
> > > > > > Como a Venda contém informações sobre os produtos, seus valores e
> > etc
> > > > > > isso funciona bem. Quando quero o total apenas chamo o método
> > > > > > getTotalDoDesconto() da implementação de desconto que
> > > > > > estiver em uso.
> > > > > >
> > > > > > A questão é:
> > > > > > Como eu poderia COMBINAR múltiplas formas de desconto
> > > simultaneamente?
> > > > > > O modelo atual apenas
> > > > > > permite usar uma por vez.
> > > > > >
> > > > > > Seria melhor criar um array dentro de Venda contendo as
> > > implementações
> > > > > > de desconto em uso e depois loopar para somar o total dos
> descontos
> > > pra
> > > > > > então
> > > > > > aplicar ao total do pagamento?
> > > > > >
> > > > > > Ou há algum jeito melhor de fazer isso (com menos acoplamento)
> > talvez
> > > > > > usando um Decorator ou outro padrão de projeto? Qual outro? Como
> > > > > > seria?
> > > > > >
> > > > > > Alguém já deve ter passado por isso.
> > > > > > Valeu pessoal.
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > [As partes desta mensagem que não continham texto foram removidas]
> > > > >
> > > > >
> > > > >
> > > > > ------------------------------------
> > > > >
> > > > > Python-Brasil
> > > > > http://www.python.org.br/wiki/AntesDePerguntar
> > > > > Links do Yahoo! Grupos
> > > > >
> > > > >
> > > > >
> > > >
> > > > [As partes desta mensagem que não continham texto foram removidas]
> > > >
> > > >
> > > >
> > >
> > >
> > > [As partes desta mensagem que não continham texto foram removidas]
> > >
> > >
> > >
> > > ------------------------------------
> > >
> > > Python-Brasil
> > > http://www.python.org.br/wiki/AntesDePerguntar
> > > Links do Yahoo! Grupos
> > >
> > >
> > >
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
> >
> >
>
>
> [As partes desta mensagem que não continham texto foram removidas]
>
>
>
> ------------------------------------
>
> Python-Brasil
> http://www.python.org.br/wiki/AntesDePerguntar
> Links do Yahoo! Grupos
>
>
>


[As partes desta mensagem que não continham texto foram removidas]



------------------------------------

Python-Brasil
http://www.python.org.br/wiki/AntesDePerguntar
Links do Yahoo! Grupos

<*> Para visitar o site do seu grupo na web, acesse:
    http://br.groups.yahoo.com/group/python-brasil/

<*> Para sair deste grupo, envie um e-mail para:
    [hidden email]

<*> O uso que você faz do Yahoo! Grupos está sujeito aos:
    http://br.yahoo.com/info/utos.html


Reply | Threaded
Open this post in threaded view
|

Re: Strategy com o quê?

sidtj
In reply to this post by Luciano Ramalho
Luciano, valeu!

Sua afirmação e exemplos citados (inclusive a referência do livro)
esclareceram melhor a questão. Começo a ver que o python permite sim a
utilização de padrões para resolver problemas conhecidos, porém, de maneira
diferente do 'convencional' em outras linguagens. Isso é até interessante.
Não preciso do python para fins de lucro atualmente e estou estudando pois
gosto de diversificar meu conhecimento em linguagens (após java, php, ruby
básico (por enquanto), e uma outra que me recuso a citar o nome).

Na realidade quero agradecer a todos, afinal, todos têm sido prestativos.
Mas achei tua explicação com mais propriedade e mais embasada.

Valeu.



2011/7/13 Luciano Ramalho <[hidden email]>

> **
>
>
> 2011/7/13 Luciano Ramalho <[hidden email]>:
>
> > O Bruce Eckel, autor do Thinking in Java, tem um esboço de livro sobre
> > padrões de projeto que tenta ser aplicável em Python também (ele deu
> > um workshop sobre isso na Globalcode em São Paulo antes da PythonBrasl
> > 2008 que foi no Rio).
>
> Talvez o livro seja este, mas não tive tempo de conferir:
>
> http://www.mindviewinc.com/Books/Python3Patterns/Index.php
>
>
> --
> Luciano Ramalho
> programador repentista || stand-up programmer
> Twitter: @luciano
>
>  
>


[As partes desta mensagem que não continham texto foram removidas]



------------------------------------

Python-Brasil
http://www.python.org.br/wiki/AntesDePerguntar
Links do Yahoo! Grupos

<*> Para visitar o site do seu grupo na web, acesse:
    http://br.groups.yahoo.com/group/python-brasil/

<*> Para sair deste grupo, envie um e-mail para:
    [hidden email]

<*> O uso que você faz do Yahoo! Grupos está sujeito aos:
    http://br.yahoo.com/info/utos.html


Reply | Threaded
Open this post in threaded view
|

Re: Strategy com o quê?

George Silva
In reply to this post by Luciano Ramalho
Em quarta-feira, 13 de julho de 2011 08:39:47, Luciano Ramalho escreveu:

> 2011/7/13 Luciano Ramalho <[hidden email]
> <mailto:luciano%40ramalho.org>>:
>  > O Bruce Eckel, autor do Thinking in Java, tem um esboço de livro sobre
>  > padrões de projeto que tenta ser aplicável em Python também (ele deu
>  > um workshop sobre isso na Globalcode em São Paulo antes da PythonBrasl
>  > 2008 que foi no Rio).
>
> Talvez o livro seja este, mas não tive tempo de conferir:
>
> http://www.mindviewinc.com/Books/Python3Patterns/Index.php
>
> --
> Luciano Ramalho
> programador repentista || stand-up programmer
> Twitter: @luciano
>
>

O que eles querem dizer é isto aqui ó:

arquivo discounts.py:

def getDiscountCash(price):
    # calcula o valor do desconto no pagamento à vista
    pass

def getDiscountA(price):
    # calcula o valor do desconto na forma A
    pass

def getDiscount
B(price):
    # calcula o valor do desconto da forma B
    pass

arquivo "x":

def calculateFinalPrice(purchase,discountMethod):
    return purchase.Price - discountMethod(purchase.Price)

Você neste caso, trata discountMethod como um objeto qualquer, podendo
atributir à ele um valor.

Abra seu console python e teste

IDLE 1.2.1      
>>> def dobro(a):
        return a*2

>>> def triplo(a):
        return a*3

>>> metodo = dobro
>>> metodo(4)
8

Abraços

--
--------------------------------
George Rodrigues da Cunha Silva
Desenvolvedor GIS
http://geoprocessamento.net
http://blog.geoprocessamento.net
Reply | Threaded
Open this post in threaded view
|

Re: Strategy com o quê?

sidtj
In reply to this post by Magno Junior
>> Em python voce NUNCA irá precisar de uma interface. ( Somos muito grato por
> isso).

Isso é MUITO interessante. A ideia de ver como se implementa isso no
modo python já tá me deixando bem loko de curiosidade.
Obrigado.

>
> Essa é a parte legal. Voce não terá que alterar nenhuma linha de código.
>
Já aqui, não quero falar sem base, mas acho isso impossível sem um bom projeto.
Mas vou continuar estudando pra entender o que você quis dizer com isso.
Só acho exagero pois senão todo mundo aprenderia python e adeus ao
problema de manutenção de sistemas.
Mas obrigado.


2011/7/13 Magno Junior <[hidden email]>:

> Em 12 de julho de 2011 23:57, <[hidden email]> escreveu:
>
>> > Magno, obrigado.
>> > Mas a quanto a ser necessária, é.
>> >
>> > Não entendi.
>> O que quis dizer é que sempre que voce receber um objeto por parametro e
>> chamar o metodo getTotalPreco, voce terá uma resposta, independente do que
>> quer que seja esse objeto. Basta ele ter o método implementado. Não precisa
>> de uma interface.
>>
>> Bom, se eu for pensar assim então eu tenho que pensar que *nunca* vou
>> precisar de uma interface porque no final das contas basta haver a
>> implementação e "isso é o que importa".
>>
>> Em python voce NUNCA irá precisar de uma interface. ( Somos muito grato por
> isso).
>
>
>>
>> Já o seu outro argumento eu discordo. Qual a vantagem que eu tenho em
>> > esperar surgir a necessidade de um design pattern, ou seja, surgir um
>> > problema pra só então eu utilizá-lo? Se o problema já é conhecido e já
>> tem
>> > solução conhecida e provada (o design pattern) então por que esperar o
>> > problema acontecer no sistema?
>> >
>> > Novamente, o que quis dizer foi:
>> Se existe um problema com solução conhecida, resolve com os padrões já
>> conhecidos. A questão é: Existe mesmo esse problema?
>>
>> A resposta a questão é: sim. Existe um problema.
>> E sim, existe a solução. E sim, ela está documentada.
>>
>> Nem sempre é necessário eu adicionar complexidade quando ela é
>> desnecessária
>> somente pelo fato de ser um padrão de projeto.
>>
>> Esse definitivamente não é o caso. Isso é um mito na cabeça das pessoas de
>> que,
>> em geral, se você usa um design pattern você está "adicionando
>> complexidade".
>> Muito pelo contrário, estou FUGINDO dela. Complexidade não se mede por
>> quanto
>> código eu tenho mas sim por quanto código eu TEREI QUE MUDAR numa futura
>> manutenção.
>>
>
> Essa é a parte legal. Voce não terá que alterar nenhuma linha de código.
>
>
>> É verdade que alguns exageram. Mas este não é o caso.
>> Veja a definição do Strategy (wikipedia):
>>
>> Definir uma família de algoritmos <http://pt.wikipedia.org/wiki/Algoritmo>
>> e
>> encapsular cada algoritmo como uma
>> classe<http://pt.wikipedia.org/wiki/Classe_%28programa%C3%A7%C3%A3o%29>,
>> permitindo assim que elas possam ter trocados entre si. Este padrão permite
>> que o algoritmo possa variar independentemente dos clientes que o utilizam.
>>
>> Utilizar o padrão Strategy quando:
>>
>> •um objecto deve ser parametrizado com um de vários algoritmos, os quais
>> podem ser encapsulados e representados* por uma única
>> interface<http://pt.wikipedia.org/wiki/Interface>
>> .*
>>
>>
>> Por exemplo: Tenho uma classe Pessoa, então para acessar essa classe vou
>> criar uma interface PessoaFacade para evitar o acoplamento desta classe com
>> as outras do modelo (???). Isso faz algum sentido? depende muito.
>>
>> Desculpe mas isso não tem nada a ver com o problema proposto.
>> **
>> E antes que isso vire um flame, não precisa responder se não souber.
>> Pois agradeço sinceramente a contribuição até aqui.
>>
>>
>> 2011/7/12 Magno Junior <[hidden email]>
>>
>> > **
>> >
>> >
>> > Em 12 de julho de 2011 11:51, <[hidden email]> escreveu:
>> >
>> >
>> > > Magno, obrigado.
>> > > Mas a quanto a ser necessária, é.
>> > >
>> > > Não entendi.
>> > O que quis dizer é que sempre que voce receber um objeto por parametro e
>> > chamar o metodo getTotalPreco, voce terá uma resposta, independente do
>> que
>> > quer que seja esse objeto. Basta ele ter o método implementado. Não
>> precisa
>> > de uma interface.
>> >
>> >
>> > Já o seu outro argumento eu discordo. Qual a vantagem que eu tenho em
>> > > esperar surgir a necessidade de um design pattern, ou seja, surgir um
>> > > problema pra só então eu utilizá-lo? Se o problema já é conhecido e já
>> > tem
>> > > solução conhecida e provada (o design pattern) então por que esperar o
>> > > problema acontecer no sistema?
>> > >
>> > > Novamente, o que quis dizer foi:
>> > Se existe um problema com solução conhecida, resolve com os padrões já
>> > conhecidos. A questão é: Existe mesmo esse problema?
>> > Nem sempre é necessário eu adicionar complexidade quando ela é
>> > desnecessária
>> > somente pelo fato de ser um padrão de projeto.
>> >
>> > Por exemplo: Tenho uma classe Pessoa, então para acessar essa classe vou
>> > criar uma interface PessoaFacade para evitar o acoplamento desta classe
>> com
>> > as outras do modelo (???). Isso faz algum sentido? depende muito.
>> >
>> >
>> > > Inclusive, este do strategy é um caso *muito* comum. Sem usá-lo posso
>> > ficar
>> > > em apuros depois se eu precisar acrescentar novas formas de desconto.
>> Vai
>> > > tomar muitoo tempo e ainda vai causar repetição desnecessária.
>> > >
>> > > Mas a minha outra dúvida do e-mail anterior ainda está aberta a quem
>> > puder
>> > > esclarecer (agradeço desde já).
>> > >
>> > > Obrigado.
>> > >
>> > > 2011/7/12 Magno Junior <[hidden email]>
>> > >
>> > > > **
>> > > >
>> > > >
>> > > > Em 12 de julho de 2011 08:33, Rodrigo Ferreira de Souza <
>> > > > [hidden email]> escreveu:
>> > > >
>> > > >
>> > > > > No python todas as funções são objetos, o que significa que voce
>> não
>> > > > > precisa
>> > > > > criar o padrão strategy.. só passar a função como parâmetro como se
>> > > fosse
>> > > > >
>> > > >
>> > > > Um outro ponto que colocam muito é que padrões de projeto devem
>> emergir
>> > > > naturalmente do modelo, e não construir o modelo com base nos padrões
>> > de
>> > > > projeto.
>> > > >
>> > > > Por exemplo, acho que a sugestão da Venda com Desconto ( acho que
>> isso
>> > > > seria
>> > > > o padrão decorator), pode até ser interssante, mas somente com as
>> > > > informações que possuimos não da pra dizer até que ponto é realmente
>> > > > necessária.
>> > > >
>> > > >
>> > > > > uma variável qualquer.
>> > > > >
>> > > > > 2011/7/12 <[hidden email]>
>> > > > >
>> > > > > > **
>> > > > > >
>> > > > > >
>> > > > > > [first post here]
>> > > > > >
>> > > > > > Pessoal, estou tentando aqui com a galera do python (que estou
>> > > > > > estudando há alguns dias).
>> > > > > > A tendência é ter mais entendidos de OOP aqui do que no outro
>> grupo
>> > > > > > onde postei essa dúvida.
>> > > > > > Se alguém puder ajudar agradeço muito:
>> > > > > >
>> > > > > > Tenho um sistema de pagamentos.
>> > > > > > Nele preciso criar um esquema com estratégias de desconto.
>> > > > > > Então resolvi usar o Strategy assim:
>> > > > > >
>> > > > > > <<interface>> (ou abstract)
>> > > > > > IEstrategiaDeDesconto
>> > > > > > public getTotalDoDesconto(Venda v)
>> > > > > >
>> > > > > > Agora as implementações:
>> > > > > >
>> > > > > > class DescontoPorTotalMaiorQueX
>> > > > > >
>> > > > > > class DescontoPorCupom
>> > > > > >
>> > > > > > class DescontoPorFormaDePagto
>> > > > > >
>> > > > > > Como a Venda contém informações sobre os produtos, seus valores e
>> > etc
>> > > > > > isso funciona bem. Quando quero o total apenas chamo o método
>> > > > > > getTotalDoDesconto() da implementação de desconto que
>> > > > > > estiver em uso.
>> > > > > >
>> > > > > > A questão é:
>> > > > > > Como eu poderia COMBINAR múltiplas formas de desconto
>> > > simultaneamente?
>> > > > > > O modelo atual apenas
>> > > > > > permite usar uma por vez.
>> > > > > >
>> > > > > > Seria melhor criar um array dentro de Venda contendo as
>> > > implementações
>> > > > > > de desconto em uso e depois loopar para somar o total dos
>> descontos
>> > > pra
>> > > > > > então
>> > > > > > aplicar ao total do pagamento?
>> > > > > >
>> > > > > > Ou há algum jeito melhor de fazer isso (com menos acoplamento)
>> > talvez
>> > > > > > usando um Decorator ou outro padrão de projeto? Qual outro? Como
>> > > > > > seria?
>> > > > > >
>> > > > > > Alguém já deve ter passado por isso.
>> > > > > > Valeu pessoal.
>> > > > > >
>> > > > > >
>> > > > >
>> > > > >
>> > > > > [As partes desta mensagem que não continham texto foram removidas]
>> > > > >
>> > > > >
>> > > > >
>> > > > > ------------------------------------
>> > > > >
>> > > > > Python-Brasil
>> > > > > http://www.python.org.br/wiki/AntesDePerguntar
>> > > > > Links do Yahoo! Grupos
>> > > > >
>> > > > >
>> > > > >
>> > > >
>> > > > [As partes desta mensagem que não continham texto foram removidas]
>> > > >
>> > > >
>> > > >
>> > >
>> > >
>> > > [As partes desta mensagem que não continham texto foram removidas]
>> > >
>> > >
>> > >
>> > > ------------------------------------
>> > >
>> > > Python-Brasil
>> > > http://www.python.org.br/wiki/AntesDePerguntar
>> > > Links do Yahoo! Grupos
>> > >
>> > >
>> > >
>> >
>> > [As partes desta mensagem que não continham texto foram removidas]
>> >
>> >
>> >
>>
>>
>> [As partes desta mensagem que não continham texto foram removidas]
>>
>>
>>
>> ------------------------------------
>>
>> Python-Brasil
>> http://www.python.org.br/wiki/AntesDePerguntar
>> Links do Yahoo! Grupos
>>
>>
>>
>
>
> [As partes desta mensagem que não continham texto foram removidas]
>
>
>
> ------------------------------------
>
> Python-Brasil
> http://www.python.org.br/wiki/AntesDePerguntar
> Links do Yahoo! Grupos
>
>
>


------------------------------------

Python-Brasil
http://www.python.org.br/wiki/AntesDePerguntar
Links do Yahoo! Grupos

<*> Para visitar o site do seu grupo na web, acesse:
    http://br.groups.yahoo.com/group/python-brasil/

<*> Para sair deste grupo, envie um e-mail para:
    [hidden email]

<*> O uso que você faz do Yahoo! Grupos está sujeito aos:
    http://br.yahoo.com/info/utos.html


Reply | Threaded
Open this post in threaded view
|

Re: Strategy com o quê?

Luciano Ramalho
In reply to this post by sidtj
2011/7/12  <[hidden email]>:
> [first post here]


Olá, [hidden email], vocë poderia se apresentar, pelo menos dizer
seu nome, já que iniciou uma longa conversa?

Eu sou o Luciano Ramalho, como você pode ver pelo coabeçalho do e-mail
e a assinatura que eu uso para me identificar.

A lista Python-Brasil é uma lista onde pessoas trocam idéias. Elas às
vezes discordam, e às vezes até brigam, mas a motivação principal é
positiva, e a atitude que domina também é. O fundamental é que somos
pessoas de carne e osso, não meras caixas postais.

[várias mensagens depois...]
2011/7/12  <[hidden email]>:
> E antes que isso vire um flame, não precisa responder se não souber.

Essa atitude não é legal. Primeiro porque a mera citação da palavra
flame cosuma degenerar nisso mesmo. Segundo porque "não precisa
responder se não souber" é uma ofensa potentcial a todos os que já
responderam, pois eu não sei se você considerou a minha resposta
anterior digna do sua considearação ou não, e talvez outros colegas
estejam pensando o mesmo.

Uma das coisas mais sábias que eu já ouvi é "todo mundo faz o melhor
que pode". Cada um que dá uma resposta, está dando o melhor que pode
dentro de suas circunstâncias e limitações (tempo, experiência,
conhecimento etc.).

Então se você inicia uma conversa com uma pergunta (e foi uma ótima
conversa esta que você começou) é legal que a última frase do seu
e-mail mais recente seja realmente sincera:

2011/7/12  <[hidden email]>:
> Pois agradeço sinceramente a contribuição até aqui.

Valeu, SIDTJ!

Ah, sim, voltando ao tema: se você não esudou ainda o conceito de
callables, ou seja o uso de funções como objetos e a implementação de
objetos invocáveis em Python, você realmente não está em condições de
implementar o padrão Strategy em Python.

Seja muito bem vindo, SIDTJ!

[ ]s
Luciano



>
> Pessoal, estou tentando aqui com a galera do python (que estou
> estudando há alguns dias).
> A tendência é ter mais entendidos de OOP aqui do que no outro grupo
> onde postei essa dúvida.
> Se alguém puder ajudar agradeço muito:
>
> Tenho um sistema de pagamentos.
> Nele preciso criar um esquema com estratégias de desconto.
> Então resolvi usar o Strategy assim:
>
> <<interface>> (ou abstract)
> IEstrategiaDeDesconto
> public getTotalDoDesconto(Venda v)
>
> Agora as implementações:
>
> class DescontoPorTotalMaiorQueX
>
> class DescontoPorCupom
>
> class DescontoPorFormaDePagto
>
>
> Como a Venda contém informações sobre os produtos, seus valores e etc
> isso funciona bem. Quando quero o total apenas chamo o método
> getTotalDoDesconto()  da implementação de desconto que
> estiver em uso.
>
> A questão é:
> Como eu poderia COMBINAR múltiplas formas de desconto simultaneamente?
> O modelo atual apenas
> permite usar uma por vez.
>
> Seria melhor criar um array dentro de Venda contendo as implementações
> de desconto em uso e depois loopar para somar o total dos descontos pra então
> aplicar ao total do pagamento?
>
> Ou há algum jeito melhor de fazer isso (com menos acoplamento) talvez
> usando um Decorator ou outro padrão de projeto? Qual outro? Como
> seria?
>
> Alguém já deve ter passado por isso.
> Valeu pessoal.
>
>
> ------------------------------------
>
> Python-Brasil
> http://www.python.org.br/wiki/AntesDePerguntar
> Links do Yahoo! Grupos
>
>
>



--
Luciano Ramalho
programador repentista || stand-up programmer
Twitter: @luciano
123