You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@hivemind.apache.org by Jean-Yves Sironneau <ep...@gmail.com> on 2006/01/25 23:43:35 UTC
services without setters
Hello,
I think it can be interesting for hivemind to bypass setters for setting
services properties, because in a lot of cases setters are just declared
for hivemind to be able to
set a property but should not be used otherwise for example :
public int getPublisherActivationPeriod() {
return this.publisherActivationPeriod;
}
public void setPublisherActivationPeriod(int
publisherActivationPeriod) {
this.publisherActivationPeriod = publisherActivationPeriod;
}
This would be possible to not have to declare the second method by
bypassing the setters method (if the security configuration of
the JVM allow it).
Of course it's just in the implementations so it's just a verbosity
issue, and a way to see what is "settable" and what is not. What do you
think ?
Jean-Yves
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
RE: services without setters
Posted by James Carman <ja...@carmanconsulting.com>.
You also use setters in your unit tests to inject your dependencies. Of
course, you can use constructor-based dependency injection in HiveMind to
avoid the setters. Typically, the setters aren't exposed via the service
interface, so it's no big deal. I personally like setter-based rather than
constructor-based, but that's really just a personal preference I guess.
Most IDEs these days will generate your setters for you. But, it just makes
for more code to maintain.
-----Original Message-----
From: Jean-Yves Sironneau [mailto:epsout@gmail.com]
Sent: Wednesday, January 25, 2006 5:44 PM
To: hivemind-user@jakarta.apache.org
Subject: services without setters
Hello,
I think it can be interesting for hivemind to bypass setters for setting
services properties, because in a lot of cases setters are just declared
for hivemind to be able to
set a property but should not be used otherwise for example :
public int getPublisherActivationPeriod() {
return this.publisherActivationPeriod;
}
public void setPublisherActivationPeriod(int
publisherActivationPeriod) {
this.publisherActivationPeriod = publisherActivationPeriod;
}
This would be possible to not have to declare the second method by
bypassing the setters method (if the security configuration of
the JVM allow it).
Of course it's just in the implementations so it's just a verbosity
issue, and a way to see what is "settable" and what is not. What do you
think ?
Jean-Yves
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org