You've discovered part of the quirkiness of CFMX's OO implementation.
I don't know what others do in this regard but I would create a base class for my whole company and use that as the type. E.G....
com.<companyname>.library.user.UserGateway
(or whatever sort of path you might want to use to store "core" things for you organisation)
And then use that as the fully qualified path and make my app-specific classes inherit from that. Your "library" version would do nothing except publish the interface (or it could even provide some core methods -
e.g. maybe it only needs to be initialised with which database is the authentication one and then it knows how to do everything else).
And - btw - if anyone has a different solution than either of the above, I'd be keen to hear it.
Now - having said all of that - somewhere along the line things have to know about things. Really it is all about WHERE the knowledge is.
If you only have one UserGateway class and it is so core to your organisation that you are never likely to have a different one (and you will always extend or modify the code in that class) then you can create a dependency on it inside Authenticator.
It's OK to break OO rules (especially in a language implementation that does not fully support all relevant OO constructs) - but you have to know when you are breaking them and why you are doing it and what the cost is going to be in the long run. If UserGateway is only used in three places and changing the code in those places wont break your system, how long does it take to change a few lines of code? And if you document this even someone coming to your code long after you are gone will be able to work it all out.
Regards,
Gary
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]
