Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #23503 > unrolled thread

Re: DI/wiring

Back to article view | Back to comp.lang.java.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: DI/wiring Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-04-18 09:32 -0700
    Re: DI/wiring Lew <lewbloch@gmail.com> - 2013-04-23 23:32 -0700
    Re: DI/wiring Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2013-04-24 09:44 +0200
    Re: DI/wiring Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-04-24 09:19 -0300
    Re: DI/wiring Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-04-24 08:40 -0700
      Re: DI/wiring Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-04-24 13:05 -0300
      Re: DI/wiring Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2013-04-24 21:14 +0200
    Re: DI/wiring Joerg Meier <joergmmeier@arcor.de> - 2013-04-24 20:13 +0200
      Re: DI/wiring markspace <markspace@nospam.nospam> - 2013-04-24 14:22 -0700

#23503 — Re: DI/wiring

On 4/18/13 9:03 AM, Stefan Ram wrote:
>    I have »invented« myself something that also seems to be
>    known as »dependency injection« or »wiring«. I am doing it
>    in pure Java SE without any framework, for example:
I think "invented" is the wrong word here. Discovered? Uncovered? 
Migrated toward? Maybe reinvented.
>
> component0.acceptPrinter( printer0 );
> component0.acceptEngine(  engine0  );
> component1.acceptPrinter( printer0 );
> component1.acceptEngine(  engine0  );
> component2.acceptPrinter( printer0 );
> component2.acceptEngine(  engine0  );
Why aren't those simply setters? Must you go against all convention in 
every possible way?
>
>    . Now, however, every component needs to have all that
>    boilerplate code like an implementation of »acceptPrinter«
>    and so.
Most IDE's will generate getters/setters for you automatically. Yes, it 
is boilerplate, but it is useful to have such explicit declarations.
>
>    The whole project would need much less boilerplate, if
>    I would just do:
>
> Globals.printer = printer0;
> Globals.engine = engine0;
>
>    and every component that needs the printer or the engine
>    would just use »Globals.printer« or »Globals.engine«, just
>    as we use the »global« »java.lang.System.out«.
>
>    Some people, however, frown upon such globals. But would
>    it be that bad?
It depends on the scope of your project, the size of your team, and the 
expected lifespan of the product.

For a small project with a one person team for a product which will last 
a week, that's absolutely fine.

For any other combination, it *will* cause problems at some point.  A 
new feature will require component0 to use a different printer than 
component2, and component1 uses a different engine. Or, someone will 
unwittingly change the value of a Global value, and effect more than 
they intended. Especially if this ends up being concurrent code.

java.lang.System.out is global accessible because it truly is a global 
entity.  It isn't just "an output", it is *the* system's output.  I 
wouldn't want to use it in most code directly, but instead pass around a 
PrintWriter, PrintStream, or even an OutputStream.  That way, if the 
main program wants to redirect the output of the library, it can do so 
with no hoops to jump through.

[toc] | [next] | [standalone]

#23612

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:
> 
>       »Sir, please accept this bread!«
> 
>   this sound fine to me, while
> 
>       »Sir, please set this bread!«
> 
>   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 Paleolithic Age.
It was established by Sun's attempt to promote JavaBeans. It's the part that really 
stuck, as it turns out Java really needed a good implementation for attributes.
What we got are getters (accessor methods) and setters (mutator methods), so 
named for the conventional 'getXyz()' and 'setXyz()' patterns for naming the 
wrapper methods for the 'xyz' attribute.

... [snip] ...

>> Why aren't those simply setters?
> 
>   Actually I do not know the definition of »setter« 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 methods 
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 not.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#23614

On 24/04/2013 06:34, Stefan Ram allegedly wrote:
> Daniel Pitts <newsgroup.nospam@virtualinfinity.net> 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:
> 
>       »Sir, please accept this bread!«
> 
>   this sound fine to me, while
> 
>       »Sir, please set this bread!«
> 
>   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!
> 
>   But I am not a native English speaker. May be I am missing
>   something here.
> 
>   Imagine I would have called the reportAcceptor
>   »reportSetter«. This would have made no sense to me! This
>   object is supposed to accept a report, not to set a report!
>   The report is already »set« by the caller, the callee is
>   just asked to kindly consider accepting it!
> 
>> Why aren't those simply setters?
> 
>   Actually I do not know the definition of »setter« that you
>   take as basis for your question. When do you call something
>   a setter?
> 

You give that bread to the hungry man to be his property; yet bread is
not a property of a hungry man (except perhaps a boolean one). Or again
without the wordplay: you give that bread to the hungry man to be his
possession; yet bread is not a quality of a hungry man. The closest
equivalent in engineering terms is that you give it to him for
/processing/, to do something with, to consume. If he's hungry enough,
he'll eat it; if he's gluten sensitive, he won't; if he's a Goldman
Sachs banker, he'll short the bread and long the Yen. In either case,
"bread" is not a quality of any man, hungry or not. Hungriness, however,
is. And while on an object whose purpose would be to re-form the
Austro-Hungarian empire, you might define a method call "acceptHungary",
you wouldn't call a method "acceptHungry" if you wanted to determine
whether not that object was hungry or not, would you? Or, to put it
differently, imagine you had your own Goldman-Sachs banker to play with,
and could resist the urge to arrange his timely and painful demise (it's
a stretch, but bear with me). There might be numerous qualities of his
you might want to alter: his hairdo, his clothing, his level of naked
short selling... In each case, you'd use a setter: "setHairdo",
"setClothing", "setLevelOfNakedShortSelling". It would be totally
pointless to say, for instance, "acceptLevelOfShortSelling". Why, he'd
probably double down on whatever you specify on his own anyway!

HTH,

-- 
DF.

[toc] | [prev] | [next] | [standalone]

#23622

On 04/24/2013 01:34 AM, Stefan Ram wrote:
> Daniel Pitts <newsgroup.nospam@virtualinfinity.net> 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:
>
>        »Sir, please accept this bread!«
>
>    this sound fine to me, while
>
>        »Sir, please set this bread!«
>
>    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!
>
>    But I am not a native English speaker. May be I am missing
>    something here.
>
>    Imagine I would have called the reportAcceptor
>    »reportSetter«. This would have made no sense to me! This
>    object is supposed to accept a report, not to set a report!
>    The report is already »set« by the caller, the callee is
>    just asked to kindly consider accepting it!
>
>> Why aren't those simply setters?
>
>    Actually I do not know the definition of »setter« that you
>    take as basis for your question. When do you call something
>    a setter?
>
Others have provided good responses. Here's my take.

You certainly know the getX/setX convention, and you also certainly know 
that this convention is sometimes required by frameworks. So I won't 
belabour that point.

You're already making one valuable point, which is that if getX and setX 
don't sound quite right, that maybe the X is not really a "property" of 
the object being modelled by the Java class.

 From a natural language standpoint, perhaps it would help to translate 
getX and setX to "get value of (my) X" and "set value of (my) X", 
because that's really what the accessor naming shorthand means. If 
phrased this way you'll see that there is a reasonable interpretation of 
what the callee is doing, not the caller. Although the getter sounds 
even better in natural English as "get and provide value of (my) X".

If after this mental translation the natural language meaning of the 
getter/setter is still not sensible, then maybe you really don't have an 
object property.

That's really the OO definition of accessor methods: the operations for 
retrieving or modifying the value of the property of an object. The 
naming conventions do interfere somewhat with the options we've then got 
available for methods that describe behaviour, but they had to call them 
something.

AHS

[toc] | [prev] | [next] | [standalone]

#23624

On 4/23/13 9:34 PM, Stefan Ram wrote:
> Daniel Pitts <newsgroup.nospam@virtualinfinity.net> 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:
>
>        »Sir, please accept this bread!«
>
>    this sound fine to me, while
>
>        »Sir, please set this bread!«
>
>    sounds strange. In
>
> object.acceptNumber( 2 )
>
>    I tell the object to accept the number, but what is
>
> object.setNumber( 2 )
The word "accept" has a different connotation in programming. It is 
often used for the visitor pattern.  The "get" and "set" words are 
referring to "the value of a property."

>
>    supposed to mean? How can the object set the number 2?
>    This makes no sense!
Translating "setNumber" becomes "Set your property called 'number' to 
the value '2'"
>
>    But I am not a native English speaker. May be I am missing
>    something here.
Besides the fact that "set" and "get" are convention, they are actually 
an integral part of the JavaBean concept, which is far more than just a 
convention. Introspector expects get, is, and set prefixes on property 
names.
>
>    Imagine I would have called the reportAcceptor
>    »reportSetter«. This would have made no sense to me! This
>    object is supposed to accept a report, not to set a report!
>    The report is already »set« by the caller, the callee is
>    just asked to kindly consider accepting it!
>
>> Why aren't those simply setters?
>
>    Actually I do not know the definition of »setter« that you
>    take as basis for your question. When do you call something
>    a setter?
A setter is a method which sets the value of a property. A setter method 
starts with the literal "set", and ends with the capitalized camel-case 
name of the property.  The property *may* be backed by a field, but that 
isn't a requirement.


Usually "accept" is an object that can be visited (in the Visitor 
Pattern). Generally, classes which can be visited will implement an 
abstract "void accept(Visitor visitor)" method, and visitor will 
implement an interface with many "visit(???)" methods. One for each 
static type of visitable.  The accept/visit is needed in languages which 
only have single-dispatch polymorphism.

The point is, your use of the word "accept" may cause less confusion to 
an English major, but will cause more confusion to the average computer 
programmer. You are writing in Java, not in English.

Thanks,
Daniel.

[toc] | [prev] | [next] | [standalone]

#23626

On 04/24/2013 12:47 PM, Stefan Ram wrote:
> Daniel Pitts <newsgroup.nospam@virtualinfinity.net> writes:
>> A setter is a method which sets the value of a property. A setter method
>> starts with the literal "set", and ends with the capitalized camel-case
>> name of the property.  The property *may* be backed by a field, but that
>> isn't a requirement.
>
>    Thanks for your helpful answer! I might still continue to
>    use »accept« sometimes, but I see your point.
>
>> The point is, your use of the word "accept" may cause less confusion to
>> an English major, but will cause more confusion to the average computer
>> programmer. You are writing in Java, not in English.
>
>    You have triggered a boilerplate quotation of mine
>    (not intended to contradict your paragraph!):
>
>        »I've found that some of the best [Software ]developers
>        of all are English majors. They'll often graduate with
>        no programming experience at all, and certainly without
>        a clue about the difference between DRAM and EPROM.
>
>        But they can write. That's the art of conveying
>        information concisely and clearly. Software development
>        and writing are both the art of knowing what you're going
>        to do, and then lucidly expressing your ideas.«
>
> http://praisecurseandrecurse.blogspot.com/2007/03/english-majors-as-programmers.html
>
That's been my experience too, English and history majors notably. 
PoliSci also not bad, basically anyone who has been called upon to do 
research, express themselves well and clearly.

Strikes me that the people who design languages - albeit smart - don't 
always have that background. And I wish they didn't artificially choose 
keywords or syntax just to be different from another language...which 
they damned well do.

AHS

[toc] | [prev] | [next] | [standalone]

#23630

On 24/04/2013 20:41, Stefan Ram allegedly wrote:
> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>> Thanks for your helpful answer! I might still continue to
>> use »accept« sometimes, but I see your point.
> 
>   It might have to do with the following aspect:
> 
>   The contract of the object O says:
> 
>       »Before the other methods of O can be
>       used, the method
> 
> acceptRunnable( java.lang.Runnable )
> 
>       has to be called once with an object
>       implementing java.lang.Runnable.«
> 
>   (Similar contracts apply often to the
>   classes I write in such cases.)
> 
>   Nowhere does the contract say that a
>   »property Runnable« exists or is set.
> 
>   A perfectly fine implementation of
>   »acceptRunnable« might be:
> 
> public void acceptRunnable( final java.lang.Runnable runnable )
> {}
> 
>   The client cannot observer what the object actually does
>   with the runnable object. Therefore, »setRunnable« might not
>   be an appropriate name for such a method.
> 

But Shirley, the object's contract specifies what it does with the
Runnable and when it does it, does it not?

Also, what is the contract of the acceptRunnable method itself? Does it
have side-effects?

-- 
DF.

[toc] | [prev] | [next] | [standalone]

#23628

On 24 Apr 2013 04:34:21 GMT, Stefan Ram wrote:

>   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:

>       »Sir, please accept this bread!«

>   this sound fine to me, while

>       »Sir, please set this bread!«

>   sounds strange. In 

To add to all the excellent replies: a better example would be changing
channels on your TV - you don't use your remote to ask your TV to "accept"
channel 1, you tell it to "set" the channel to 1. Various other words with
basically the same meaning would work as well - switchChannel(Channel c),
changeChannel, but as said, they mean the same as "set", and "set" is the
one the general public has settled on (likely due to its similarity to its
logical counterpart: "get").

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

[toc] | [prev] | [next] | [standalone]

#23632

On 4/24/2013 11:13 AM, Joerg Meier wrote:
>
> To add to all the excellent replies: a better example would be changing
> channels on your TV - you don't use your remote to ask your TV to "accept"
> channel 1, you tell it to "set" the channel to 1.

Set phasers on stun?

I may be creating a backronym here, but to me the idea of changing state 
on an object via "set" goes back to terminology used in circuit theory, 
when bi-stable latches where used for memory.  One state was "set" and 
the other state was "reset."  So when you added some state you were 
generally using the "set" line to do so.

<http://en.wikipedia.org/wiki/Flip-flop_%28electronics%29>

So this would be a technical term, not related directly to English 
language use of the same name.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web