Skip to Content.
Sympa Menu

gang-of-4-patterns - RE: [gang-of-4-patterns] discuss the usage of Strategy DP

gang-of-4-patterns AT lists.cs.illinois.edu

Subject: Design Patterns discussion

List archive

RE: [gang-of-4-patterns] discuss the usage of Strategy DP


Chronological Thread 
  • From: "Santana, Luis" <luis.santana AT eds.com>
  • To: gang-of-4-patterns AT cs.uiuc.edu, Pablo Schor <pablo.schor AT lobruno.com.ar>
  • Cc: Zhai <myzhai AT yahoo.com.cn>
  • Subject: RE: [gang-of-4-patterns] discuss the usage of Strategy DP
  • Date: Wed, 3 Mar 2004 13:01:33 -0600
  • List-archive: <http://mail.cs.uiuc.edu/pipermail/gang-of-4-patterns/>
  • List-id: Design Patterns discussion <gang-of-4-patterns.cs.uiuc.edu>

Hi Pablo,
I see your point and I think it all comes down to the context and the
requirements for Zhai's actual implementation... Have you noticed that
originally Zahi mentioned the Strategy Pattern and then Abstract Factory and
the Bridge patterns appeared in the picture? .. Strategy is a behavioral,
Abstract Factory is a creational and Bridge is an structural pattern which
means that all of them have different intentions...

Zhai mentions two different implementations (CFileParaAccess and
CDatabaseParaAccess) of the same abstract class (CParaAccess)... How will
the application decide when to instantiate a CFileParaAccess and when to use
a CDatabaseParaAccess? The suggestion for the Abstract Factory comes from
this perspective... But you guys are right, if it is not necessary to create
anything then there is no need for an Abstract Factory...

Cheers,

Luis Santana.

-----Original Message-----
From: Pablo Schor
[mailto:pablo.schor AT lobruno.com.ar]

Sent: Wednesday, March 03, 2004 12:38 PM
To: Santana, Luis;
gang-of-4-patterns AT cs.uiuc.edu
Cc: Zhai
Subject: Re: [gang-of-4-patterns] discuss the usage of Strategy DP


Luis, I would go with Zhai.

I would use the Strategy design pattern, since the interface is the same,
and easier to develop and implement. Abstract Factory, as its name states,
is a factory that is abstract, means that you use it to create something
that you're going to use. In this scenario, as far as I understand, you
don't need to create anything, and in addition Abstract Factory is more
complex and has more overhead.

I'd analyze the Bridge pattern, for me was always the best way to separate
interface from implementation.


Pablo



----- Original Message -----
From: "Santana, Luis"
<luis.santana AT eds.com>
To:
<gang-of-4-patterns AT cs.uiuc.edu>
Cc: "Zhai"
<myzhai AT yahoo.com.cn>
Sent: Wednesday, March 03, 2004 2:31 PM
Subject: RE: [gang-of-4-patterns] discuss the usage of Strategy DP


> I agree with Eduardo, without knowing much about the context, the best
> suitable pattern would be "Abstract Factory"... The 'family' of your
product
> is "CParaAccess" and your "concrete" products would be
> "CFileParaAccess"
and
> "CDatabaseParaAccess".
>
> Regards,
>
> Luis Santana
>
> -----Original Message-----
> From: Zhai
> [mailto:myzhai AT yahoo.com.cn]
> Sent: Wednesday, March 03, 2004 8:24 AM
> To: Eduardo Franco;
> gang-of-4-patterns AT cs.uiuc.edu
> Subject: Re: [gang-of-4-patterns] discuss the usage of Strategy DP
>
>
> At first, I try to use Abstract Factory to design the
> system. According to the intend of Abstract Factory,
> it can produce a family of products. But in our
> system, we do not know what the family of products is.
> So we next consider to use Strategy design pattern.
> we need more advice.
>
> --- Eduardo Franco
> <eduardo.franco AT pulso.com.br>
> 的正文:> I don't think the Strategy is the best
> pattern for
> > your problem. I don't
> > even know much about the context your are developing
> > the system, but
> > AFAICS the best suitable pattern is the "Abstract
> > Factory".
> >
> > [..]
> >
> > "Provide an interface for creating families of
> > related or dependent
> > objects without specifying their concrete classes."
> >
> > [..]
> >
> > This pattern let you vary families of product
> > objects when the
> > "Strategy" pattern let you vary an algorithm which I
> > don't think is your
> > real problem.
> >
> > Regards,
> >
> > --
> > Eduardo Franco
> >
> > Zhai wrote:
> > > In a software system, we meet the following
> > > requirements:
> > > a client program, when running, have to set or
> > get a
> > > parameter, named paraValue.
> > > But the parameter paraValue could be stored in a
> > file
> > > named filePara, or in a relation
> > > database, such as Oracle. Now we design an
> > abstract
> > > class "CParaAccess", with two
> > > public virtual functions setPara() and getPara()
> > to
> > > set and get the parameter.
> > > There are two subclasses "CFileParaAccess" and
> > > "CDatabaseParaAccess" inherited from "CParaAccess", all implement
> > > setPara() and getPara(). However in "CFileParaAccess" and
> > > "CDatabaseParaAccess", the principle to implement
> > > setPara() and getPara() is different.
> > > In the design we can understand the client had
> > two
> > > strategies to set/get the
> > > parameter, i.e. from a file or a database. so can
> > we
> > > think our design cohere
> > > with the Strategy design pattern? If not, which
> > > pattern could we use to improve
> > > the design?
> > > thx.
> >
> >
> > _______________________________________________
> > gang-of-4-patterns mailing list
> > gang-of-4-patterns AT cs.uiuc.edu
> >
> http://mail.cs.uiuc.edu/mailman/listinfo/gang-of-4-patterns
>
> _________________________________________________________
> Do You Yahoo!?
> 完全免费的雅虎电邮,马上注册获赠额外60兆网络存储空间
> http://cn.rd.yahoo.com/mail_cn/tag/?http://cn.mail.yahoo.com
>
> _______________________________________________
> gang-of-4-patterns mailing list
> gang-of-4-patterns AT cs.uiuc.edu
> http://mail.cs.uiuc.edu/mailman/listinfo/gang-of-4-patterns
>
> _______________________________________________
> gang-of-4-patterns mailing list
> gang-of-4-patterns AT cs.uiuc.edu
> http://mail.cs.uiuc.edu/mailman/listinfo/gang-of-4-patterns






Archive powered by MHonArc 2.6.16.

Top of Page