Re: DI/wiring
Stefan Ram wrote:
Daniel Pitts writes:
Why aren't those simply setters? Must you go against all convention in=
every possible way?
I just had to remember that remark, when I read a method
name of mine that made me smile myself, it was the name
acceptReportAcceptor
. Here is some more context:
public void acceptReportAcceptor( final ReportAcceptor reportAcceptor )
{ this.reportAcceptor = reportAcceptor; }
. But now, honestly, when one sees a hungry man, and gives
him some bread and says:
=BBSir, please accept this bread!=AB
this sound fine to me, while
=BBSir, please set this bread!=AB
sounds strange. In
object.acceptNumber( 2 )
I tell the object to accept the number, but what is
object.setNumber( 2 )
supposed to mean? How can the object set the number 2?
This makes no sense!
It makes perfect sense, assuming you don't reject the convention.
But I am not a native English speaker. May be I am missing
something here.
This really doesn't have anything to do with native English, or really
English at all except as a basis for technical terminology.
What you are missing, deliberately at a guess, is the convention set
recommended for all serious Java programmers.
Every profession has its argot. The meaning of 'setXyz()' and 'getXyz()' in=
Java is a matter of domain-specific terminology.
Your analysis is utterly correct modeling methods as actions, or messages,=
depending on the methodology by which you describe programs. In a word,
behaviors. So yes, in that sense you tell the object to accept an argument.
In UML you model behaviors, or methods, below the line below attributes.
In Java, unlike C# and some other languages, there is not a direct
implementation of attributes, modeled differently from behavioral methods.
One could use elevated-visibility member variables, 'public Xyz xyz;', but=
this practice is decried. Instead, by nearly universal convention in Java, =
one
uses specific JavaBean-compliant names for methods that wrap these
members and provide attribute characteristics.
This convention has been around since the Java equivalent of the Paleolithi=
c Age.
It was established by Sun's attempt to promote JavaBeans. It's the part tha=
t really
stuck, as it turns out Java really needed a good implementation for attribu=
tes.
What we got are getters (accessor methods) and setters (mutator methods), s=
o
named for the conventional 'getXyz()' and 'setXyz()' patterns for naming th=
e
wrapper methods for the 'xyz' attribute.
.... [snip] ...
Why aren't those simply setters?
Actually I do not know the definition of =BBsetter=AB that you
take as basis for your question. When do you call something
a setter?
Aye, therein lies the rub. It is a vocabulary issue.
A setter is a mutator method taking a single argument corresponding to
a type attribute, named in the JavaBean pattern of 'setXyz(Xyz xyz)' for
a hypothetical attribute 'xyz' of type 'Xyz'. It is one of a pair of method=
s
used to give Java full power to express a type attribute, the other being=
the 'getXyz()' accessor method.
There are advantages to following the convention, not least of which is
the ability to communicate in full bandwidth with knowledgeable Java
programmers. Many tools (IDEs, rich-application platforms, etc.) take
advantage of this convention and other JavaBean conventions to provide
robust, component-based, rapidly-developed functionality.
It's really not such a bad thing to follow Java conventions. Really it's no=
t.
--
Lew