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: "Chris Finlayson" <cfinlayson AT vls-inc.com>
  • To: <gang-of-4-patterns AT cs.uiuc.edu>
  • Subject: RE: [gang-of-4-patterns] discuss the usage of Strategy DP
  • Date: Wed, 3 Mar 2004 13:03:15 -0700
  • Importance: Normal
  • 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:

Microsoft has an example of just such a thing in their "Microsoft
Application Blocks", which is basically examples of applying design patterns
to specific problem domains in .NET languages. Regarldess of whether you're
using .NET, it's a good example that deals with just what you're looking
for.

In particular, get the "Configuration Management" application block. This
is an example of one having to get or set parameters where the storage
provider could be XML, a relational DB, or the registry. It's unclear
exactly how the storage provider is determined in Zhai's context. In the
Configuration Management application block, it is determined by a
user-configurable application settings file, but it need not be; it can be
anything you want.

As for as what design pattern is used, it's the Strategy.

They have interfaces all storage providers use for reading/writing data (one
for just reading/one for writing&reading)
The interface expects the parameter to come in as an XML Node, regardless of
the underlying storage provider
Specific storage providers (Registry, XML, DB) are
The concrete storage provider is set at runtime based on the configuration
file.
The storage provider takes the XML node, and transforms it however it needs
to be transformed to the underlying storage mechanism.

--Chris.



> -----Original Message-----
> From:
> gang-of-4-patterns-admin AT cs.uiuc.edu
> [mailto:gang-of-4-patterns-admin AT cs.uiuc.edu]On
> Behalf Of
> Santana, Luis
> Sent: Wednesday, March 03, 2004 12:02 PM
> To:
> gang-of-4-patterns AT cs.uiuc.edu;
> Pablo Schor
> Cc: Zhai
> Subject: RE: [gang-of-4-patterns] discuss the usage of Strategy DP
>
>
> 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
>
>
> _______________________________________________
> 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