struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Graham" <dgraham1...@hotmail.com>
Subject Re: Architecture advice....
Date Mon, 29 Jul 2002 22:02:10 GMT

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" <home@michael-delamere.de>
>Reply-To: "Struts Users Mailing List" <struts-user@jakarta.apache.org>
>To: "Struts Users Mailing List" <struts-user@jakarta.apache.org>
>Subject: Re: Architecture advice....
>Date: Tue, 30 Jul 2002 00:04:48 +0200
>
>near bottom :-)
>
>----- Original Message -----
>From: "Eddie Bush" <ekbush@swbell.net>
>To: "Struts Users Mailing List" <struts-user@jakarta.apache.org>
>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:struts-user-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
><mailto:struts-user-help@jakarta.apache.org>
> >
>
>
>--
>To unsubscribe, e-mail:   
><mailto:struts-user-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: 
><mailto:struts-user-help@jakarta.apache.org>
>




_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com


--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>


Mime
View raw message