Makes sense. Thanks! Best Wishes, Peter
On 7/11/07 12:27 PM, "Barney Boisvert" <[EMAIL PROTECTED]> wrote: > 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 >>
