If it's simply semantics that are the issue (too much similarity
between a standard mutator and one used strictly during object
instantiation) why not just devise a purpose-driven nomenclature?
instead of "setDependentObject" call it "injectDependentObject".
Standardize on a naming convention, then enhance Coldspring to
physically remove that method from the interface once the object has
been fully instantiated so that it is non-existent, could never be
confused with anything, and won't show up in any metadata for the
object. Basically, a temporary method that exists within the class for
the specific purpose of injecting dependent objects, and once
instantiated those methods (known by their naming convention) are
discarded.

Just a thought.

Doug  :0)


On 7/11/07, 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
>

--
Barney Boisvert
[EMAIL PROTECTED]
http://www.barneyb.com/

Got Gmail? I have 100 invites.



Reply via email to