That's what interfaces (and API documentation) are for. Say you have a service object that has some setters as part of it's business operations. Those are part of the business interface that clients of the service interact with. But if a given implementation of the interface requires collaborators, those are clearly not part of the interface.
In the Java world, you declare an interface that represents your objects, and then implement those interfaces. Your bean factory creates beans of the implementation type, but all references to those beans are typed with the interface (not the implementation). This keeps the implementation details of the active implementation hidden from consumers, and allows swapping out implementations (e.g. with mock objects for testing) with almost no fuss. Since we don't yet have interfaces in CF (yes, I'm aware of CF8's addition of them), we're kind of stuck. You have to document what methods are for what, and just hope people listen, at least for now. cheers, barneyb On 7/11/07, Peter Bell <[EMAIL PROTECTED]> wrote:
I also tend not to use constructor injection so much these days, but I still don't love setter injection as there is no real way of distinguishing intent between setters that should never be called by your app from those that should be (is setXXX() part of the API of your UserService or just something you need CS to inject). Always thought that wasn't ideal, but I haven't really seen much is the CF or Java worlds about it. Anyone got any thoughts? Best Wishes, Peter
-- Barney Boisvert [EMAIL PROTECTED] http://www.barneyb.com/ Got Gmail? I have 100 invites.
