Design Patterns discussion

["Prabodh Saha" <prabodhs AT ivycomptech.com>]

Hi Zhai,
        From your mails I understand that u are willing
        to provide an API (for the client applications)
        to access different parameters whose values can
        be stored in different types of storage (your
        present universe being - file and db).

        I am not sure about one thing here, whether you
        will like to gather all the parameter values in
        one shot.

        IF YES
        ======
                Provide an interface in which a method
                will take the configuration file pointer
                as input
                (do whatever all u have discussed so far,
                and populate an object with paraValue's)
                and return the object to your client.

                Your client will pass the config-file-pointer
                to your api, will get the populated object
                from it
                and continue using this object
                for rest of its life time
                OR
                till the time he refreshes this object, similarly as above,
                with some other configuration file.


        IF NO
        =====
                Then your client application needs to read
                the config file. Remember which paraValue
                to be accessed from which dataStorage type.
                Since client application will need this
                information (randomly) throughout its lifetime.
                [u may store this info in a map {(paraName, storageType)}]

                In this case I suggest you use Factory Method.
                Write a class "YourAPI" with a static method:

                public static CParaAccess createParaAccess(String type) {
                    if (type == "file")
                        return new CFileParaAccess();
                    if (type == "db")
                        return new CDatabaseParaAccess();

                    print("Panic: Unknown Type - Can't create ParaAccess");
                }

                Your client should ideally have a "map" data structure
                to hold {(db, paraAccess1), (file, paraAccess2), ...}
                where
                        paraAccess1 = YourAPI.createParaAccess("db");
                        paraAccess2 = YourAPI.createParaAccess("file");

                Also your client needs to remember the type of the
                paraValue storage type (may be in another map - populated
                while reading the config file).

                Now, depending on the paraValue storage type,
                your clint needs to lookup, from map, for paraAccess1 or 2
                and use it to get the paraValue.

                Note:
                        This design segregates your client totally.
                        It just needs to include your library class YourAPI
                        and the interface CParaAccess. That's all.

                        The hierarchy of CFileParaAccess & CDatabaseParaAccess
                        remains as you have suggested from the beginning.

                        If tomorrow you need another type of storage,
                        just add another sibling to
                        CFileParaAccess/CDatabaseAccess and add another
                        line in createParaAccess() factory method.
                        Your client remains un-touched.


Regards,
Prabodh


-----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 Zhai
Sent: Thursday, March 04, 2004 8:25 AM
To: 
cfinlayson AT vls-inc.com;
 
gang-of-4-patterns AT cs.uiuc.edu
Subject: RE: [gang-of-4-patterns] discuss the usage of Strategy DP


Hi,
  Thank all of you.
  Now it seems that the context is important. And I
did not mention it at beginning.
  In fact, we want to provide an API class for
parameter management in our system, like MICROSOFT's
Configuration Management Application Block for .NET(
  I do not know it before). The abstract class
"CParaAccess" is
  the interface. Clients can use the interface to
access their parameters form a file or a databse, even
from a registry.
  In order to do so, they would instantiate a
CFileParaAccess or a CDatabaseParaAccess, decided by a
configuration file. Moreover, a client can access some
parameters form a file and  the other parameters from
a database. So it is the client that determines which
subclass to instantiate. And in run time, the client
can define a variable "paraPtr" to point to the
instance and change its content. that is, paraPtr can
be changed from "new CFileParaAccess" to "new
CDatabaseParaAccess", or inversely. we only provide a
library with the client to invoke. According to Chris
Finlayson<cfinlayson AT vls-inc.com>,
 it's the Strategy.
  Additionally, can we use the Factory Method design
pattern to help clients to create the instances? we
can design an abstract class CParaAccessFactory and
two subclasses "CFileParaAccessFactory"
  and "CDatabaseParaAccessFactory", then clients can
use these factories to create their needed class. That
is, we use Factory Method
  and Strategy design patterns together to design our
library.
thx.




 --- Chris Finlayson 
<cfinlayson AT vls-inc.com>
的正文：> 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."
> > > >
> > > > [..]
> > > >
>
=== message truncated ===

_________________________________________________________
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