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]
