Hi Andrew, Yerp, I think we are on the same page, but talking past each other (if thats the correct term) heh.
none the less, what i've outlined previously should be the answer you are looking for? It does sound like you are doing the facade which has a "abstract factory" type class in its composition. Do a google on AbstractFactory Pattern + Facade and you'll see some more examples (mostly java, but can easily translate into CF). On 11/28/05, Andrew Scott <[EMAIL PROTECTED]> wrote: > Scott, > > Yeah well it is going to be a common API, the idea is that in this case it > is a standard file import that I am working on. But the requirements are > going to be different per client, so I am building it in place where the API > remains the same, and the inner functions of the objects takes care of the > business logic differences between the clients. > > So for example > > <cfset obj = CreateObject( façade ) /> > <cfset obj.OpenFile( Filename ) /> > <cfset obj.ImportData() /> > <cfset obj.Close() /> > > Now the above is very simple, but the real work will be in the ImportData > and in this case as I have said it will be different logic depending on the > client, so I want the façade / abstract layer or what ever you want to call > it, to know that the right class will be loaded for this client. And if this > client has not had a class setup then it will load a default class, with > basic logic. > > Wasn't really sure if I was explaining myself properly either. > > > Regards > Andrew Scott > Analyst Programmer > > CMS Transport Systems > Level 2/33 Bank Street > South Melbourne, Victoria, 3205 > > Phone: 03 9699 7988 - Fax: 03 9699 7976 > > Quote: > Gravity is a myth, the Earth sucks. > ---------------------------------------------------------------------------- > -------------------------- > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Scott Barnes > Sent: Monday, 28 November 2005 12:21 PM > To: [email protected] > Subject: Re: [CFCDev] Facade - how to? > > On 11/28/05, Andrew Scott <[EMAIL PROTECTED]> wrote: > > Scott, > > > > No what I am looking at has nothing to do with the actual signon. > > My Bad, ;) (sorry each email is a new clue hehehe ). > > > To explain this a little better, this module that I am creating is > designed > > for one of our customers, but it will be different depending on the > > customer. > > > > So I was looking at a façade to minimise the code, now if I understand > this > > correctly. I should be able to write a piece of code that knows nothing > > about what it has to do, just do what it is told too. > > Well it does need to know something about what it has to do, ie there > needs to be a uniform API between the client and the facade thats > consistent. How it does stuff under the hood, thats up to you. I mean > you could have a facade class which the client talks to, feeds in > arguments, based on these arguments carries out an abstractFactory > style lifcycle (ie DAO's are a classic. Depending on type, you could > slot in the appropriate SQL/ORACLE/MySQL.DAO in place. Each DAO > follows the same method signatures as its siblings, but the actual > "core how" is different). > > > > > For example a CRUD might have a façade to the database drivers and the > > façade works out what database driver to use. > > Yeah, possibly.. but sounds more like an AbstractFactory then Facade > (semantics aside, I understand what you mean though). > > > So in this case, I want a façade to have methods called, but depending on > > the requirement it either asks for a car, or a bike object, and in this > case > > if the required module for scooter was required but is not defined as an > > option to use then we use the default methods. > > Depends, typically the bike/car/scooter have common methods > (accellerate, brake etc) which follows the same approach in which > AbstractFactory lives for. Now on the event, you want to > "PopWheelie()" for both Bike/Scooter ( unless you have a stunt car) > this can still be done, but based on the Facade level, not the > AbstractFactory.. In that, a Facade by nature is well... a layer that > abstracts the innerworkings of how its children operate by providing a > uniform api in front - much like the old KFC "how may i help you" > analogy. > > What I am getting at, is you would have a Facade like this: > > var facade = createObject('component","com.mossyblog.facade").init(); > > facade.setType("bike"); > -- instance.AFC = > createObject("component","com.mossyblog.abstractFactory".init( > arguments.type); > > facade.accellerate(); > // Check for usual stuff (AFC Exists, aswell as type is defined and is > correct) > -- instance.AFC.getInstance().accellerate(); > > facade.break(); > // Check for usual stuff (AFC Exists, aswell as type is defined and is > correct) > -- instance.AFC.getInstance().accellerate(); > > facade.popWheelie(); > // Check for usual stuff (AFC Exists, aswell as type is defined and is > correct) > -- instance.AFC.getInstance().popWheelie(); > > facade.isCallValid( methodCall ); > -- I slotted this one in, to simply store your validation in the one spot). > > So in a nutshell, what I am doing there is i'm keeping all the facade > specific logic housed within the class. The AFC specific logic in its > respective part (does cfc exist, is it known, where to get it etc). > > > > So I guess if I had a database operation, and I didn't need to know what > > database I will be connecting to I would have a façade to interface to, > > which calls the crud methods without me knowing which database calls to > make > > etc. And if the mySQL database hasn't been implemented then it would be > > using generic database calls. > > > > Hope that clears it up a bit better. Still learning here. > > " I'm a newbie" is my mantra, so its all good. No shame in asking > "how" to solve a problem, vs sitting there assuming. > > Hope the above helps out? > > -- > Regards, > Scott Barnes > http://www.mossyblog.com > > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email to > [email protected] with the words 'unsubscribe cfcdev' as the subject of the > email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting > (www.cfxhosting.com). > > An archive of the CFCDev list is available at > www.mail-archive.com/[email protected] > > > > > > > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email to > [email protected] with the words 'unsubscribe cfcdev' as the subject of the > email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting > (www.cfxhosting.com). > > An archive of the CFCDev list is available at > www.mail-archive.com/[email protected] > > > -- Regards, Scott Barnes http://www.mossyblog.com ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
