Ron, Honestly, I don't see any Dependency Injection going on in your example (you only have one "model" CFC anyways!).
Seems like what you've written is a fancy way to allow "calling" or "client" code to request an object not by name or by type but by a feature it has... but how will this aid in resolving dependencies WITHIN your model (which is what DI is for)? The Phython example object has a bunch of RequiredFeature() calls (which is why it IS the Service Locator pattern - the object is going out and locating it's dependencies). However, this is why I don't like Service Locator (including this odd approach to it): Sure your CFC's are decoupled from each other. However, they are ALL coupled to the Service Locator. With DI, the CFCs are still decoupled, but they don't have that extra dependency on the Service Locator. So it's just taking the "loosely coupled" idea that one final step - where dependencies are outwardly expressed (usually via. setter-methods) and it is up to their "container" to push them in (INJECTION!). >From the ColdSpring perspective, what you're trying to accomplish is autowiring "byFeature", where right now we do it either "byName" or "byType". It's a cool idea, but it's real-world practicality seems rather low and could potentially cause a lot of runtime confusion - what if you have 10 objects that provide the same "feature" - which is the best to use? As the developer you'd hope it doesn't matter, but I personally wouldn't sleep well on that assumption. If you don't like XML, that's great - I'd really love for someone to write a programmatic interface to ColdSpring (which J2EE Spring has - as well as HiveMind and PicoContainer - two other IoC/Di containers). Lastly, I'll mention that ColdSpring fully supports "Duck-Typing", even when it's asked to autowire components together (when autowire is "byName" rather than "byType"). -Dave Ross >>> [EMAIL PROTECTED] 04/25/06 11:22 AM >>> I really wasn't getting ColdSpring, and I stumbled across http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/413268, Zoran Isailovski's "Dependency Injection The Python Way" recipe. A calling object just specifies that the provider of a given feature must meet certain assertions. Then the calling object doesn't need to know anything about the actual provider. There's an involved discussion of whether this better fits the criteria for "DependencyInjection" or "ServiceLocator", but I like the way it works, whatever it's called. It has a solid "five star" rating on ASPN's site. I figured since Pythonistas have been doing duck-typed OOP for a long time, it might port over to ColdFusion, and maybe I'd learn as I went. So, I ported it over to CFML. Maybe someone else already did it and I just didn't see it. It's nice, not too heavy * about 200 lines total in the CFC's that make it work. No XML sit-ups, either * I like everything being "on the fly" instead of set up in advance. Anyway, there's a demo page and a test page in the zip file at: http://uber.engineer.co.summit.oh.us/assets/app_tools/dependency_injection.zip If you want to have a play, you'll need to tweak the CFC path in all but the "testCFC.cfc" file. If you do take a look, and you like what it does, please pass along any suggestions to tighten up the code or improve the idea. For that matter, if it's handy, but I'm calling it by the wrong Pattern, let me know that, too. It was mainly a learning exercise for me, but I think I might just use it for real. Ron ---------------------------------------------------------- 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] ----------------------------------------- CONFIDENTIALITY NOTICE: This email and any attachments may contain confidential information that is protected by law and is for the sole use of the individuals or entities to which it is addressed. If you are not the intended recipient, please notify the sender by replying to this email and destroying all copies of the communication and attachments. Further use, disclosure, copying, distribution of, or reliance upon the contents of this email and attachments is strictly prohibited. To contact Albany Medical Center, or for a copy of our privacy practices, please visit us on the Internet at www.amc.edu. ---------------------------------------------------------- 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]
