Not sure I completely get what you're asking but the (Microsoft) Security Application Block takes an interesting approach to this kind of problem.
Each system is considered a Provider and implements the I<ProviderType>Provider interface, i.e IAuthenticationProvider, IRoleProvider, IProfileProvider etc.
Information about each System is stored in a config file which is read on Application startup.
When I want the system to do anything I create an I<ProviderType>Factory instance which reads the config file and instatiates it. i.e myAuthenticationProvider = IAuthenticationProviderFactory.Create("provider_name_in_config_file")
I can then use this any of the methods provided by the I<ProviderType>Proivder interface. i.e myAuthenticationProvider.Authenticate().
The useful thing about this implementation is that it means you have a number of different systems all doing Authenticate() in there own special way but you don't need to know anything about it. In fact if you do use a config file, you could change the Provider for another one and your application wouldn't even need to know about it.
I think this is a long was of saying 'Is the abstract factory pattern any use here' I've probably got the name wrong again (happens all the time) so thought it better write it out ;)
Cheers,
Pete (aka lad4bear)
On 26/10/05, Barney Boisvert <[EMAIL PROTECTED]> wrote:
But an Interface is just a contract of the
> methods a class provides.
That's a very narrow definition. Method contracts are only useful in
languges with compile-time type checking (which CF doesn't have), and
for runtime environments that don't allow dynamic method refactoring
(which CF does allow).
The other benefit of interfaces (and the vastly more important one
with regard to CF) is that they allow you to specify that a single
object is an instance of multiple types, without having to have all
those types in the object's inheritance hierarchy. For example, I can
say my User object implements the Employee, Parent, and Fireman
interfaces, without having to make some kind of horribly nasty
inheritance hierarchy.
cheers,
barneyb
On 10/26/05, Gary Menzel <[EMAIL PROTECTED]> wrote:
> While I dont know the exact situation - and what you want to achieve with
> all the different objects from within Coldfusion - there is another OO
> pattern that you did not mention and that is one of Interfaces (and
> Implements).
>
> It could be possible to have totally discrete classes to handle all the
> validation and handling details of each - but have each Implement an
> Interface that provides all the basic user functionality.
>
> However, Coldfusion doesn't support Interfaces (although I have seen a few
> attempts to provide them). But an Interface is just a contract of the
> methods a class provides. So, as long as you document that your classes
> Implement a certain Interface, then you can be sure that instances of those
> classes will have the necessary methods for you to call when you need the
> generic information.
>
> Inheritance may work by having a "BasicUser" class and then inherit from
> that for the specialisations.
>
> Composition and Inheritance could still be used by having your basic class
> provide a "detail" method (as well as overriding "validation" methods). The
> "detail" method could return the additional detail for the specialisations.
>
> Don't know if that helps answer your question though.
>
> Regards,
> Gary Menzel
>
--
Barney Boisvert
[EMAIL PROTECTED]
360.319.6145
http://www.barneyb.com/
Got Gmail? I have 100 invites.
----------------------------------------------------------
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).
CFCDev is supported by New Atlanta, makers of BlueDragon
http://www.newatlanta.com/products/bluedragon/index.cfm
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).
CFCDev is supported by New Atlanta, makers of BlueDragon
http://www.newatlanta.com/products/bluedragon/index.cfm
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
