Thanks Graham,
I think I will stick with your advice. It has certainly convinced me; now I
just have to convince the guys at work :-) !
Regards,
Michael
----- Original Message -----
From: "David Graham" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, July 30, 2002 12:02 AM
Subject: Re: Architecture advice....
>
> Naming services is certainly a great way to do configurable factory
methods
> but I think what you want is still the facade.
>
> >From: "Michael Delamere" <[EMAIL PROTECTED]>
> >Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> >To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> >Subject: Re: Architecture advice....
> >Date: Tue, 30 Jul 2002 00:04:48 +0200
> >
> >near bottom :-)
> >
> >----- Original Message -----
> >From: "Eddie Bush" <[EMAIL PROTECTED]>
> >To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> >Sent: Monday, July 29, 2002 11:37 PM
> >Subject: Re: Architecture advice....
> >
> >
> > > David Graham wrote:
> > >
> > > > Now we're onto "how to design a factory method" :-). So if you have
> > > > many different service objects you could just compose your
> > > > ServiceFacade of these objects and publish their interfaces. This
is
> > > > the true use of the facade pattern so your code doesn't need to know
> > > > about all of the objects behind the facade. You would do this like
> >so:
> > > > ServiceFacade{
> > > > private SpecialServiceClass special;
> > > >
> > > > public doService(){
> > > > special.doService(); //delegate call to internal service object
> > > > }
> > > > }
> > > >
> > > > Notice that all interaction with SpecialServiceClass is done through
> > > > the facade leaving you free to rip out SpecialServiceClass in the
> > > > future and replace it with something else.
> > > >
> > > > If you really want to do the factory thing you have 2 options:
> > > > 1. A factory method for each service class
> > > > public SpecialServiceClass createSpecialServiceClass()...
> > > > public SpecialService2 createSpecialService2()...
> > > >
> > > > 2. One factory method with parameter telling which type of service
> > > > class to return. public Object create("SpecialServiceClass")
> > > >
> > > > I would go for the facade pattern so most of your code only knows
> > > > about the facade and not the implementation classes.
> > > >
> > > > I hope this helps.
> > >
> > > Why not name your services. Then, use a properties file to figure out
> > > what the actual class is. If all you ever programmed to was an
> > > interface, you could switch implementations out very easily. Just
edit
> > > the properties file and restart you app!
> > >
> > > Ex:
> > >
> > > services.serviceName=com.mycompany.services.ServiceClass1
> > >
> > > ... then ...
> > >
> > > public ServiceInterface create("serviceName")
> > >
> >
> >wow, nice one Eddie. The discussion is getting better and better!
Christ,
> >there is so much to look up in order to implement your ideas (which I
think
> >are great!).
> >
> >Regards,
> >
> >Michael
> >
> >
> >
> > > Ummmm - I believe that addresses any concerns you may have, but I sure
> > > welcome suggestions! ;-)
> > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> ><mailto:[EMAIL PROTECTED]>
> > > For additional commands, e-mail:
> ><mailto:[EMAIL PROTECTED]>
> > >
> >
> >
> >--
> >To unsubscribe, e-mail:
> ><mailto:[EMAIL PROTECTED]>
> >For additional commands, e-mail:
> ><mailto:[EMAIL PROTECTED]>
> >
>
>
>
>
> _________________________________________________________________
> Send and receive Hotmail on your mobile device: http://mobile.msn.com
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
