You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user-java@ibatis.apache.org by Clinton Begin <cl...@gmail.com> on 2008/07/18 16:31:29 UTC
Re: Setters, gettes and public fields
No, it shouldn't. iBATIS will use fields, but only if it can't find the
property -- public or private...
That said, this is a really bad design and I can't imagine why on earth
you'd want to do something like that... :-)
Clinton
On Fri, Jul 18, 2008 at 8:32 AM, Davide Rogora <dr...@unionefiduciaria.it>
wrote:
> Hi,
> my company is using iBatis for our web application and we are very happy
> with it.
>
> Actually in our model classes we have private fields and public getters and
> setters (like javaBeans specification recommends).
> For some reasons we are planning to do a refactoring in our project, by
> converting private fields in public fields (but leaving the public getters
> and setters)
>
> i.e.
> *Class person before refactoring*
> public class Person {
>
> * private* String firstName;
> * private* String lastName;
>
> * public* String getFirstName() {
> * return* firstName;
> }
> * public* *void* setFirstName(String firstName) {
> * this*.firstName = firstName;
> }
>
> * public* String getLastName() {
> * return* lastName;
> }
> * public* *void* setLastName(String lastName) {
> * this*.lastName = lastName;
> }
>
> }
>
> *Class person AFTER refactoring*
> public class Person {
>
> * public* String firstName; // Changed to public
> * public* String lastName; // Changed to public
>
> * public* String getFirstName() {
> * return* firstName;
> }
> * public* *void*
> setFirstName(String firstName) {
> * this*.firstName = firstName;
> }
>
> * public* String getLastName() {
> * return* lastName;
> }
> * public* *void* setLastName(String lastName) {
> * this*.lastName = lastName;
> }
>
> }
>
> Do you think that the presence of both public field and getter and setter
> will cause problems to iBatis?
>
> Thanks,
> Davide.
>
>
>
> -----
> Davide Rogora
> Unione Fiduciaria S.p.A. - Società Fiduciaria e di Servizi delle Banche
> Popolari Italiane
> Area Informatica
> via Olmetto, 1
> 20123 Milano
> Tel. 02 72.422.423
> e-mail: drogora@unionefiduciaria.it
>
> Le dichiarazioni contenute nel presente messaggio nonché nei suoi eventuali
> allegati devono essere attribuite esclusivamente al mittente e non possono
> essere considerate come trasmesse o autorizzate da Unione Fiduciaria S.p.A.;
> le medesime dichiarazioni non impegnano Unione Fiduciaria S.p.A. nei
> confronti del destinatario o di terzi. Unione Fiduciaria S.p.A. non assume
> alcuna responsabilità per eventuali intercettazioni, modifiche o
> danneggiamenti del presente messaggio e-mail. Qualsiasi utilizzo non
> autorizzato del presente messaggio nonchè dei suoi allegati è vietato e
> potrebbe costituire reato. Se avete ricevuto erroneamente il presente
> messaggio, saremmo grati se, via e-mail, ce ne comunicaste la ricezione e
> provvedeste alla distruzione del messaggio stesso e dei suoi eventuali
> allegati.
>
>
>
> The statements and opinions espressed in this e-mail message are those of
> the author of the message and do not necessarily represent those of Unione
> Fiduciaria S.p.A. Besides, the contents of this message shall be understood
> as neither given nor endorsed by Unione Fiduciaria S.p.A. Unione Fiduciaria
> S.p.A. does not accept liability for corruption, interception or amendment,
> if any, or the consequences thereof. Any unauthorized use of this e-mail or
> any of its attachments is prohibited and could constitute an offence. If
> You are not the intended addressee please advise immediately the sender by
> using the reply facility in Your e-mail software and destroy the message and
> its attachments.
>
>
Re: R: Setters, gettes and public fields
Posted by Clinton Begin <cl...@gmail.com>.
Unfortunately, it's the cost of using Java... but not an excuse for abusing
it. :-) I don't like it anymore than you do -- I'm an ex Object Pascal and
current C# and Ruby programmer -- all three had some sort of built in
properties (or overridable attribute assignments).
C#: person.LastName = "Clinton"
Ruby: person.last_name = "Clinton"
Delphi: Person.LastName = "Clinton"
Java: person.setLastName("Clinton")
It's just how it is. You risk a lot by fighting the language. You would
SERIOUSLY be better off just using public fields exclusively and getting rid
of all properties. Then treat all of your model classes basically like
structs. Or use your own pattern...
person.lastName("Clinton"); //sets
person.lastName(); //gets
But ultimately you'd lose compatibility with a lot of frameworks by taking
either approach (iBATIS would still work with either of these by setting the
fields).
I'm not a fan of Sun's specs and standards, but this is one I recommend
submitting to....unfortunately.
Clinton
On Fri, Jul 18, 2008 at 9:07 AM, Davide Rogora <dr...@unionefiduciaria.it>
wrote:
> Clinton,
> thanks for your prompt reply.
>
> The only and unique reason we are going to do this (but we have yet to
> decide) is for code readability.
>
> i.e.
> *Before*
> person.setLastName(person.getLastName().toUppercase());
> person.setDescription(person.getFirstName() + " " + person.getLastName());
>
> *After*
> person.lastName = person.lastName.toUppercase();
> person.description = person.firstName + " " + person.lastName;
>
> For me is a lot more readable the second version (maybe because I'm an ex
> COBOL programmer :-)
>
> Davide.
>
> -----Messaggio originale-----
> *Da:* Clinton Begin [mailto:clinton.begin@gmail.com]
> *Inviato:* venerdì 18 luglio 2008 16.31
> *A:* user-java@ibatis.apache.org
> *Oggetto:* Re: Setters, gettes and public fields
>
> No, it shouldn't. iBATIS will use fields, but only if it can't find the
> property -- public or private...
>
> That said, this is a really bad design and I can't imagine why on earth
> you'd want to do something like that... :-)
>
> Clinton
>
> On Fri, Jul 18, 2008 at 8:32 AM, Davide Rogora <
> drogora@unionefiduciaria.it> wrote:
>
>> Hi,
>> my company is using iBatis for our web application and we are very happy
>> with it.
>>
>> Actually in our model classes we have private fields and public getters
>> and setters (like javaBeans specification recommends).
>> For some reasons we are planning to do a refactoring in our project, by
>> converting private fields in public fields (but leaving the public getters
>> and setters)
>>
>> i.e.
>> *Class person before refactoring*
>> public class Person {
>>
>> * private* String firstName;
>> * private* String lastName;
>>
>> * public* String getFirstName() {
>> * return* firstName;
>> }
>> * public* *void* setFirstName(String firstName) {
>> * this*.firstName = firstName;
>> }
>>
>> * public* String getLastName() {
>> * return* lastName;
>> }
>> * public* *void* setLastName(String lastName) {
>> * this*.lastName = lastName;
>> }
>>
>> }
>>
>> *Class person AFTER refactoring*
>> public class Person {
>>
>> * public* String firstName; // Changed to public
>> * public* String lastName; // Changed to public
>>
>> * public* String getFirstName() {
>> * return* firstName;
>> }
>> * public* *void*
>> setFirstName(String firstName) {
>> * this*.firstName = firstName;
>> }
>>
>> * public* String getLastName() {
>> * return* lastName;
>> }
>> * public* *void* setLastName(String lastName) {
>> * this*.lastName = lastName;
>> }
>>
>> }
>>
>> Do you think that the presence of both public field and getter and setter
>> will cause problems to iBatis?
>>
>> Thanks,
>> Davide.
>>
>>
>>
>> -----
>> Davide Rogora
>> Unione Fiduciaria S.p.A. - Società Fiduciaria e di Servizi delle Banche
>> Popolari Italiane
>> Area Informatica
>> via Olmetto, 1
>> 20123 Milano
>> Tel. 02 72.422.423
>> e-mail: drogora@unionefiduciaria.it
>>
>> Le dichiarazioni contenute nel presente messaggio nonché nei suoi
>> eventuali allegati devono essere attribuite esclusivamente al mittente e non
>> possono essere considerate come trasmesse o autorizzate da Unione Fiduciaria
>> S.p.A.; le medesime dichiarazioni non impegnano Unione Fiduciaria S.p.A. nei
>> confronti del destinatario o di terzi. Unione Fiduciaria S.p.A. non assume
>> alcuna responsabilità per eventuali intercettazioni, modifiche o
>> danneggiamenti del presente messaggio e-mail. Qualsiasi utilizzo non
>> autorizzato del presente messaggio nonchè dei suoi allegati è vietato e
>> potrebbe costituire reato. Se avete ricevuto erroneamente il presente
>> messaggio, saremmo grati se, via e-mail, ce ne comunicaste la ricezione e
>> provvedeste alla distruzione del messaggio stesso e dei suoi eventuali
>> allegati.
>>
>>
>>
>> The statements and opinions espressed in this e-mail message are those of
>> the author of the message and do not necessarily represent those of Unione
>> Fiduciaria S.p.A. Besides, the contents of this message shall be understood
>> as neither given nor endorsed by Unione Fiduciaria S.p.A. Unione Fiduciaria
>> S.p.A. does not accept liability for corruption, interception or amendment,
>> if any, or the consequences thereof. Any unauthorized use of this e-mail or
>> any of its attachments is prohibited and could constitute an offence. If
>> You are not the intended addressee please advise immediately the sender by
>> using the reply facility in Your e-mail software and destroy the message and
>> its attachments.
>>
>>
>
>
Re: R: Setters, gettes and public fields
Posted by Sundar Sankar <fa...@gmail.com>.
Hi David,
Like Clinton said, that is a bad design. We had similar
requirements and the way we did it was,
1. For upper case ;
public String getLastName()
{
return this.name.toUpperCase();
//or
/*
if(this.name!=null)
{
return this.name.toUpperCase()
}
else
return null;
*/
}
2. for description : Instead of doing the same in the calling class, i would
have a public getDescription is the person Class and that would have the
operations you would wanna do. Ex :
public String getDescription()
{
return this.getFirstName + this.getLastName();
}
Personally, I wouldnt want the properties exposed.
Good luck anyways
Regards
-S
On Fri, Jul 18, 2008 at 8:07 AM, Davide Rogora <dr...@unionefiduciaria.it>
wrote:
> Clinton,
> thanks for your prompt reply.
>
> The only and unique reason we are going to do this (but we have yet to
> decide) is for code readability.
>
> i.e.
> *Before*
> person.setLastName(person.getLastName().toUppercase());
> person.setDescription(person.getFirstName() + " " + person.getLastName());
>
> *After*
> person.lastName = person.lastName.toUppercase();
> person.description = person.firstName + " " + person.lastName;
>
> For me is a lot more readable the second version (maybe because I'm an ex
> COBOL programmer :-)
>
> Davide.
>
> -----Messaggio originale-----
> *Da:* Clinton Begin [mailto:clinton.begin@gmail.com]
> *Inviato:* venerdì 18 luglio 2008 16.31
> *A:* user-java@ibatis.apache.org
> *Oggetto:* Re: Setters, gettes and public fields
>
> No, it shouldn't. iBATIS will use fields, but only if it can't find the
> property -- public or private...
>
> That said, this is a really bad design and I can't imagine why on earth
> you'd want to do something like that... :-)
>
> Clinton
>
> On Fri, Jul 18, 2008 at 8:32 AM, Davide Rogora <
> drogora@unionefiduciaria.it> wrote:
>
>> Hi,
>> my company is using iBatis for our web application and we are very happy
>> with it.
>>
>> Actually in our model classes we have private fields and public getters
>> and setters (like javaBeans specification recommends).
>> For some reasons we are planning to do a refactoring in our project, by
>> converting private fields in public fields (but leaving the public getters
>> and setters)
>>
>> i.e.
>> *Class person before refactoring*
>> public class Person {
>>
>> * private* String firstName;
>> * private* String lastName;
>>
>> * public* String getFirstName() {
>> * return* firstName;
>> }
>> * public* *void* setFirstName(String firstName) {
>> * this*.firstName = firstName;
>> }
>>
>> * public* String getLastName() {
>> * return* lastName;
>> }
>> * public* *void* setLastName(String lastName) {
>> * this*.lastName = lastName;
>> }
>>
>> }
>>
>> *Class person AFTER refactoring*
>> public class Person {
>>
>> * public* String firstName; // Changed to public
>> * public* String lastName; // Changed to public
>>
>> * public* String getFirstName() {
>> * return* firstName;
>> }
>> * public* *void*
>> setFirstName(String firstName) {
>> * this*.firstName = firstName;
>> }
>>
>> * public* String getLastName() {
>> * return* lastName;
>> }
>> * public* *void* setLastName(String lastName) {
>> * this*.lastName = lastName;
>> }
>>
>> }
>>
>> Do you think that the presence of both public field and getter and setter
>> will cause problems to iBatis?
>>
>> Thanks,
>> Davide.
>>
>>
>>
>> -----
>> Davide Rogora
>> Unione Fiduciaria S.p.A. - Società Fiduciaria e di Servizi delle Banche
>> Popolari Italiane
>> Area Informatica
>> via Olmetto, 1
>> 20123 Milano
>> Tel. 02 72.422.423
>> e-mail: drogora@unionefiduciaria.it
>>
>> Le dichiarazioni contenute nel presente messaggio nonché nei suoi
>> eventuali allegati devono essere attribuite esclusivamente al mittente e non
>> possono essere considerate come trasmesse o autorizzate da Unione Fiduciaria
>> S.p.A.; le medesime dichiarazioni non impegnano Unione Fiduciaria S.p.A. nei
>> confronti del destinatario o di terzi. Unione Fiduciaria S.p.A. non assume
>> alcuna responsabilità per eventuali intercettazioni, modifiche o
>> danneggiamenti del presente messaggio e-mail. Qualsiasi utilizzo non
>> autorizzato del presente messaggio nonchè dei suoi allegati è vietato e
>> potrebbe costituire reato. Se avete ricevuto erroneamente il presente
>> messaggio, saremmo grati se, via e-mail, ce ne comunicaste la ricezione e
>> provvedeste alla distruzione del messaggio stesso e dei suoi eventuali
>> allegati.
>>
>>
>>
>> The statements and opinions espressed in this e-mail message are those of
>> the author of the message and do not necessarily represent those of Unione
>> Fiduciaria S.p.A. Besides, the contents of this message shall be understood
>> as neither given nor endorsed by Unione Fiduciaria S.p.A. Unione Fiduciaria
>> S.p.A. does not accept liability for corruption, interception or amendment,
>> if any, or the consequences thereof. Any unauthorized use of this e-mail or
>> any of its attachments is prohibited and could constitute an offence. If
>> You are not the intended addressee please advise immediately the sender by
>> using the reply facility in Your e-mail software and destroy the message and
>> its attachments.
>>
>>
>
>
R: Setters, gettes and public fields
Posted by Davide Rogora <dr...@unionefiduciaria.it>.
Clinton,
thanks for your prompt reply.
The only and unique reason we are going to do this (but we have yet to
decide) is for code readability.
i.e.
Before
person.setLastName(person.getLastName().toUppercase());
person.setDescription(person.getFirstName() + " " + person.getLastName());
After
person.lastName = person.lastName.toUppercase();
person.description = person.firstName + " " + person.lastName;
For me is a lot more readable the second version (maybe because I'm an ex
COBOL programmer :-)
Davide.
-----Messaggio originale-----
Da: Clinton Begin [mailto:clinton.begin@gmail.com]
Inviato: venerdì 18 luglio 2008 16.31
A: user-java@ibatis.apache.org
Oggetto: Re: Setters, gettes and public fields
No, it shouldn't. iBATIS will use fields, but only if it can't find the
property -- public or private...
That said, this is a really bad design and I can't imagine why on earth
you'd want to do something like that... :-)
Clinton
On Fri, Jul 18, 2008 at 8:32 AM, Davide Rogora
<dr...@unionefiduciaria.it> wrote:
Hi,
my company is using iBatis for our web application and we are very happy
with it.
Actually in our model classes we have private fields and public getters
and setters (like javaBeans specification recommends).
For some reasons we are planning to do a refactoring in our project, by
converting private fields in public fields (but leaving the public getters
and setters)
i.e.
Class person before refactoring
public class Person {
private String firstName;
private String lastName;
public String getFirstName() {
return firstName;
}
public void setFirstName(String firstName) {
this.firstName = firstName;
}
public String getLastName() {
return lastName;
}
public void setLastName(String lastName) {
this.lastName = lastName;
}
}
Class person AFTER refactoring
public class Person {
public String firstName; // Changed to public
public String lastName; // Changed to public
public String getFirstName() {
return firstName;
}
public void
setFirstName(String firstName) {
this.firstName = firstName;
}
public String getLastName() {
return lastName;
}
public void setLastName(String lastName) {
this.lastName = lastName;
}
}
Do you think that the presence of both public field and getter and
setter will cause problems to iBatis?
Thanks,
Davide.
-----
Davide Rogora
Unione Fiduciaria S.p.A. - Società Fiduciaria e di Servizi delle Banche
Popolari Italiane
Area Informatica
via Olmetto, 1
20123 Milano
Tel. 02 72.422.423
e-mail: drogora@unionefiduciaria.it
Le dichiarazioni contenute nel presente messaggio nonché nei suoi
eventuali allegati devono essere attribuite esclusivamente al mittente e non
possono essere considerate come trasmesse o autorizzate da Unione Fiduciaria
S.p.A.; le medesime dichiarazioni non impegnano Unione Fiduciaria S.p.A. nei
confronti del destinatario o di terzi. Unione Fiduciaria S.p.A. non assume
alcuna responsabilità per eventuali intercettazioni, modifiche o
danneggiamenti del presente messaggio e-mail. Qualsiasi utilizzo non
autorizzato del presente messaggio nonchè dei suoi allegati è vietato e
potrebbe costituire reato. Se avete ricevuto erroneamente il presente
messaggio, saremmo grati se, via e-mail, ce ne comunicaste la ricezione e
provvedeste alla distruzione del messaggio stesso e dei suoi eventuali
allegati.
The statements and opinions espressed in this e-mail message are those
of the author of the message and do not necessarily represent those of
Unione Fiduciaria S.p.A. Besides, the contents of this message shall be
understood as neither given nor endorsed by Unione Fiduciaria S.p.A. Unione
Fiduciaria S.p.A. does not accept liability for corruption, interception or
amendment, if any, or the consequences thereof. Any unauthorized use of this
e-mail or any of its attachments is prohibited and could constitute an
offence. If You are not the intended addressee please advise immediately the
sender by using the reply facility in Your e-mail software and destroy the
message and its attachments.