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

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

Java variable access

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

Contents

  Java variable access Eric Douglas <e.d.programmer@gmail.com> - 2019-04-12 06:57 -0700
    Re: Java variable access Arne Vajhøj <arne@vajhoej.dk> - 2019-04-12 10:06 -0400
      Re: Java variable access Eric Douglas <e.d.programmer@gmail.com> - 2019-04-12 07:23 -0700
        Re: Java variable access Arne Vajhøj <arne@vajhoej.dk> - 2019-04-12 10:35 -0400
        Re: Java variable access Eric Sosman <esosman@comcast-dot-net.invalid> - 2019-04-12 10:58 -0400
          Re: Java variable access Eric Douglas <e.d.programmer@gmail.com> - 2019-04-12 08:31 -0700
            Re: Java variable access Eric Sosman <esosman@comcast-dot-net.invalid> - 2019-04-12 14:40 -0400
          Re: Java variable access Arne Vajhøj <arne@vajhoej.dk> - 2019-04-12 12:31 -0400
    Re: Java variable access Eric Sosman <esosman@comcast-dot-net.invalid> - 2019-04-12 10:56 -0400
    Re: Java variable access Joerg Meier <joergmmeier@arcor.de> - 2019-04-12 23:11 +0200
      Re: Java variable access Arne Vajhøj <arne@vajhoej.dk> - 2019-04-12 21:51 -0400
        Re: Java variable access Joerg Meier <joergmmeier@arcor.de> - 2019-04-13 21:59 +0200
          Re: Java variable access Arne Vajhøj <arne@vajhoej.dk> - 2019-04-13 18:38 -0400
            Re: Java variable access Joerg Meier <joergmmeier@arcor.de> - 2019-04-16 22:08 +0200
              Re: Java variable access Eric Sosman <esosman@comcast-dot-net.invalid> - 2019-04-16 16:46 -0400
                Re: Java variable access Joerg Meier <joergmmeier@arcor.de> - 2019-04-16 23:01 +0200
                Re: Java variable access Eric Douglas <e.d.programmer@gmail.com> - 2019-04-17 06:42 -0700
                  Re: Java variable access Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2019-04-17 21:35 +0200
                    Re: Java variable access Eric Douglas <e.d.programmer@gmail.com> - 2019-04-17 14:05 -0700
                      Re: Java variable access Joerg Meier <joergmmeier@arcor.de> - 2019-04-19 10:40 +0200
                        Re: Java variable access Eric Sosman <esosman@comcast-dot-net.invalid> - 2019-04-19 17:20 -0400

Page 1 of 2  [1] 2  Next page →

#38900 — Java variable access

If one would need to get and set values of simple class variables, is it better to declare public variables or declare them private with getter/setter methods, or are there situations where you would do both?  I have been declaring all variables private though sometimes creating the getter/setter methods just seems like unnecessary busy work if making them public would accomplish the same thing.  Advantages to making them private would include 1) deprecating the getter/setter if the variable at some point is no longer needed, 2) customizing the getter/setter if you change the class to require special code to execute every time they set a value, and 3) changing the variable name without affecting any code trying to get/set the value.

[toc] | [next] | [standalone]

#38901

On 4/12/2019 9:57 AM, Eric Douglas wrote:
> If one would need to get and set values of simple class variables, is
> it better to declare public variables or declare them private with
> getter/setter methods, or are there situations where you would do
> both?  I have been declaring all variables private though sometimes
> creating the getter/setter methods just seems like unnecessary busy
> work if making them public would accomplish the same thing.
> Advantages to making them private would include 1) deprecating the
> getter/setter if the variable at some point is no longer needed, 2)
> customizing the getter/setter if you change the class to require
> special code to execute every time they set a value, and 3) changing
> the variable name without affecting any code trying to get/set the
> value.

I would use field + getter + maybe setter.

The advantages I see are:
A) The ability to have no setter which controls what can change
    the value
B) The ability to override getter and setter in sub classes
C) The ability to put more code in getter and setter

It is not much work to add the getters and maybe setters as
a modern IDE should be able to generate those.

If you don't like to see all these lines of code then
switch to Kotlin.

:-)

Arne

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

#38903

On Friday, April 12, 2019 at 10:06:30 AM UTC-4, Arne Vajhøj wrote:
> I would use field + getter + maybe setter.
> 
> The advantages I see are:
> A) The ability to have no setter which controls what can change
>     the value
> B) The ability to override getter and setter in sub classes
> C) The ability to put more code in getter and setter
> 
> It is not much work to add the getters and maybe setters as
> a modern IDE should be able to generate those.
> 
> If you don't like to see all these lines of code then
> switch to Kotlin.
> 
> :-)
> 
> Arne

That was my thought, to stick with all private/protected variables. Though it does just look cluttered if you end up with a lot of getters and setters, it does add more flexibility.  So when (if ever?) would you declare a class variable public, aside from the static final constants?

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

#38905

On 4/12/2019 10:23 AM, Eric Douglas wrote:
> On Friday, April 12, 2019 at 10:06:30 AM UTC-4, Arne Vajhøj wrote:
>> I would use field + getter + maybe setter.
>>
>> The advantages I see are:
>> A) The ability to have no setter which controls what can change
>>      the value
>> B) The ability to override getter and setter in sub classes
>> C) The ability to put more code in getter and setter
>>
>> It is not much work to add the getters and maybe setters as
>> a modern IDE should be able to generate those.
>>
>> If you don't like to see all these lines of code then
>> switch to Kotlin.
>>
>> :-)
> 
> That was my thought, to stick with all private/protected variables.
> Though it does just look cluttered if you end up with a lot of
> getters and setters, it does add more flexibility.  So when (if
> ever?) would you declare a class variable public, aside from the
> static final constants?

Practically never.

I cannot remember any need.

There are probably some exception, but ...

Arne

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

#38907

On 4/12/2019 10:23 AM, Eric Douglas wrote:
> [...]
> That was my thought, to stick with all private/protected variables. [...]
     Note that `protected' variables are accessible *everywhere*
unless your class cannot be extended at all.

-- 
esosman@comcast-dot-net.invalid
Six hundred forty-nine days to go.

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

#38908

On Friday, April 12, 2019 at 10:58:22 AM UTC-4, Eric Sosman wrote:
> > That was my thought, to stick with all private/protected variables. [...]
>      Note that `protected' variables are accessible *everywhere*
> unless your class cannot be extended at all.
> 

Ah right, protected methods are common (and I keep thinking about the use case where they must be called by a different class in the same package and sometimes forget about possibly anything extending the class), but declaring a variable protected would have the same potential issues as declaring it public unless the class is final (how common is that?).

I expect it makes sense to declare custom object variables always private.  I was thinking more simple objects.  If your variable is a String the worst that happens is something sets it to null?  If your variable is an int, even if it's supposed to be a multiple of 3, if you don't validate it with a setter you could validate it in a method that uses it's value?  If your variable is an enum?

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

#38911

On 4/12/2019 11:31 AM, Eric Douglas wrote:
> On Friday, April 12, 2019 at 10:58:22 AM UTC-4, Eric Sosman wrote:
>>> That was my thought, to stick with all private/protected variables. [...]
>>       Note that `protected' variables are accessible *everywhere*
>> unless your class cannot be extended at all.
>>
> 
> Ah right, protected methods are common (and I keep thinking about the use case where they must be called by a different class in the same package and sometimes forget about possibly anything extending the class), but declaring a variable protected would have the same potential issues as declaring it public unless the class is final (how common is that?).

     Speaking for myself, I see little practical difference between
`protected' and `public'.  Since a `protected' field or method can
be accessed by any subclass, all `protected' elements are wide open
to anyone who can extend their containing class.  Anonymous nested
classes make it particularly easy to evade protection, but it could
be done even in Old Original Java before nested classes appeared.

     I can't comment on how common or uncommon final (or effectively
final) classes may be.  Bloch advises us to "Design and document for
inheritance or else prohibit it," so readers of _Effective Java_ may
be predisposed to write such classes.

> I expect it makes sense to declare custom object variables always private.  I was thinking more simple objects.  If your variable is a String the worst that happens is something sets it to null?  If your variable is an int, even if it's supposed to be a multiple of 3, if you don't validate it with a setter you could validate it in a method that uses it's value?  If your variable is an enum?
> 

     What could happen if a String reference became null?  Almost
anything; only you can tell us how your code would react.  What could
happen if a String reference changed from "Yes" to "No"?  From "Yes"
to "Yeah"?  From "https:" to "http:"?  Almost anything.

     As to that multiple-of-three thing, would you rather find out about
a bogus value at the moment someone tries to set it, or some amount of
time later when the offender is long gone?  Is it easier to debug "My
caller is giving me a bad value" or "Somebody somewhere sometime gave
me a bad value and I'm only just now finding out about it"?

     There's nothing special about enums in this regard.  True, nobody
can make your field refer to a non-enum -- but they can make it `null',
or make it refer to a value that's valid but inconsistent with the
rest of the object's state.  See the String examples above; all of
them have analogs in enums -- also in ints, doubles, Maps, ...

-- 
esosman@comcast-dot-net.invalid
Six hundred forty-nine days to go.

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

#38910

On 4/12/2019 10:58 AM, Eric Sosman wrote:
> On 4/12/2019 10:23 AM, Eric Douglas wrote:
>> [...]
>> That was my thought, to stick with all private/protected variables. [...]
>      Note that `protected' variables are accessible *everywhere*
> unless your class cannot be extended at all.

Yes.

But what are one trying to protect against?

Normal coding style?

Those really intending on circumventing the encapsulation?

Extending a class to get access to protected fields
are almost as bad as reflection setAccessible.

Arne

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

#38906

On 4/12/2019 9:57 AM, Eric Douglas wrote:
> If one would need to get and set values of simple class variables, is it better to declare public variables or declare them private with getter/setter methods, or are there situations where you would do both?  I have been declaring all variables private though sometimes creating the getter/setter methods just seems like unnecessary busy work if making them public would accomplish the same thing.  Advantages to making them private would include 1) deprecating the getter/setter if the variable at some point is no longer needed, 2) customizing the getter/setter if you change the class to require special code to execute every time they set a value, and 3) changing the variable name without affecting any code trying to get/set the value.

     It is often the case that a field should not be set to "just any
old value," but only to a non-negative value, or to a non-null value,
or to a value consistent with that of some other field, or ...  If
such is the case (or if such might ever become the case, which means
"pretty much always"), a setter method is the suitable vehicle for
checking and enforcing the constraints.  Make the field public or
protected (or even package-private), and you'll have a very hard time
figuring out how a "must be a power of two" field got set to twelve.

     It is often the case that a class "owns" a mutable object that
must only be mutated by the class itself and not by unknown outside
agencies.  In such a case both the setter and getter methods can
make defensive copies, giving far more security than a Javadoc comment
saying "The array returned by this method must not be modified, please,
oh, please please please."

     It is sometimes the case that a field is set in a constructor or
at class initialization and is never changed thereafter.  In such a
case a `public final' field would be defensible.  `Boolean.FALSE' is
fine, but `Boolean.getFalse()' would just be silly.

     To your point (1), this seldom happens unless the purpose of the
class changes rather radically.  Yes, variables come and go as the
implementation changes -- but if the variable reflects some essential
part of the class' API, that part almost certainly reappears in a new
form.  (Consider a "getter" that does not simply retrieve a stored
value, but computes what it returns.)  If a variable *and its purpose*
both vanish, it may be time to publish a new class.

-- 
esosman@comcast-dot-net.invalid
Six hundred forty-nine days to go.

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

#38912

On Fri, 12 Apr 2019 06:57:27 -0700 (PDT), Eric Douglas wrote:

> If one would need to get and set values of simple class variables, is it better to declare public variables or declare them private with getter/setter methods, or are there situations where you would do both?  I have been declaring all variables private though sometimes creating the getter/setter methods just seems like unnecessary busy work if making them public would accomplish the same thing.  Advantages to making them private would include 1) deprecating the getter/setter if the variable at some point is no longer needed, 2) customizing the getter/setter if you change the class to require special code to execute every time they set a value, and 3) changing the variable name without affecting any code trying to get/set the value.

<https://projectlombok.org/features/GetterSetter>

You are welcome. There is also @Data, which amongst a few other things adds
@Getter and @Setter to all your fields.

Liebe Gruesse,
		Joerg

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

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

#38913

On 4/12/2019 5:11 PM, Joerg Meier wrote:
> On Fri, 12 Apr 2019 06:57:27 -0700 (PDT), Eric Douglas wrote:
>> If one would need to get and set values of simple class variables,
>> is it better to declare public variables or declare them private with
>> getter/setter methods, or are there situations where you would do both?
>> I have been declaring all variables private though sometimes creating
>> the getter/setter methods just seems like unnecessary busy work if
>> making them public would accomplish the same thing.

> <https://projectlombok.org/features/GetterSetter>
> 
> You are welcome. There is also @Data, which amongst a few other things adds
> @Getter and @Setter to all your fields.

But today wouldn't it be better to switch to Kotlin?

Arne

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

#38914

On Fri, 12 Apr 2019 21:51:28 -0400, Arne Vajhøj wrote:

> On 4/12/2019 5:11 PM, Joerg Meier wrote:
>> On Fri, 12 Apr 2019 06:57:27 -0700 (PDT), Eric Douglas wrote:
>>> If one would need to get and set values of simple class variables,
>>> is it better to declare public variables or declare them private with
>>> getter/setter methods, or are there situations where you would do both?
>>> I have been declaring all variables private though sometimes creating
>>> the getter/setter methods just seems like unnecessary busy work if
>>> making them public would accomplish the same thing.
>> <https://projectlombok.org/features/GetterSetter>

>> You are welcome. There is also @Data, which amongst a few other things adds
>> @Getter and @Setter to all your fields.
> But today wouldn't it be better to switch to Kotlin?

From the TIOBE index, 2019:

Rank Rank (2018) Language    Rating
1    1           Java        15.035%
[...]
35   None        Kotlin       0.337%

So, no. Absolutely not.

Liebe Gruesse,
		Joerg

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

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

#38915

On 4/13/2019 3:59 PM, Joerg Meier wrote:
> On Fri, 12 Apr 2019 21:51:28 -0400, Arne Vajhøj wrote:
> 
>> On 4/12/2019 5:11 PM, Joerg Meier wrote:
>>> On Fri, 12 Apr 2019 06:57:27 -0700 (PDT), Eric Douglas wrote:
>>>> If one would need to get and set values of simple class variables,
>>>> is it better to declare public variables or declare them private with
>>>> getter/setter methods, or are there situations where you would do both?
>>>> I have been declaring all variables private though sometimes creating
>>>> the getter/setter methods just seems like unnecessary busy work if
>>>> making them public would accomplish the same thing.
>>> <https://projectlombok.org/features/GetterSetter>
> 
>>> You are welcome. There is also @Data, which amongst a few other things adds
>>> @Getter and @Setter to all your fields.
>> But today wouldn't it be better to switch to Kotlin?
> 
>  From the TIOBE index, 2019:
> 
> Rank Rank (2018) Language    Rating
> 1    1           Java        15.035%
> [...]
> 35   None        Kotlin       0.337%
> 
> So, no. Absolutely not.

I am not sure that comparison is relevant.

We are not discussing Java vs Kotlin.

We are discussing Java/Lombok vs Kotlin.

The Java way is to write the getters and setters.

Arne

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

#38919

On Sat, 13 Apr 2019 18:38:35 -0400, Arne Vajhøj wrote:

> The Java way is to write the getters and setters.

If you live in 1998, sure. In this day and age, if you manually write
getters and setters, you are doing things wrong (tm). Either let your IDE
or something like Lombok do it.

Liebe Gruesse,
		Joerg

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

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

#38921

On 4/16/2019 4:08 PM, Joerg Meier wrote:
> On Sat, 13 Apr 2019 18:38:35 -0400, Arne Vajhøj wrote:
> 
>> The Java way is to write the getters and setters.
> 
> If you live in 1998, sure. In this day and age, if you manually write
> getters and setters, you are doing things wrong (tm). Either let your IDE
> or something like Lombok do it.

     What is wrong (tm) with

	public void setUnitPrice(double unitPrice) {
	    if (unitPrice <= 0 || !Double.isFinite(unitPrice)) {
	        throw new IllegalArgumentException(
	            "bad price: " + unitPrice);
	    }
	    if (unitPrice != this.unitPrice) {
	        this.unitPrice = unitPrice;
	        fireChangeEvent(this, PRICE_CHANGED);
	    }
	}

?  Is "something like Lombok" smart enough to auto-generate such code?
Smart enough to auto-generate without being prompted by annotations
bulkier than the code itself?

-- 
esosman@comcast-dot-net.invalid
Six hundred forty-five days to go.

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

#38922

On Tue, 16 Apr 2019 16:46:22 -0400, Eric Sosman wrote:

> On 4/16/2019 4:08 PM, Joerg Meier wrote:
>> On Sat, 13 Apr 2019 18:38:35 -0400, Arne Vajhøj wrote:
>>> The Java way is to write the getters and setters.
>> If you live in 1998, sure. In this day and age, if you manually write
>> getters and setters, you are doing things wrong (tm). Either let your IDE
>> or something like Lombok do it.
>      What is wrong (tm) with

> 	public void setUnitPrice(double unitPrice) {
> 	    if (unitPrice <= 0 || !Double.isFinite(unitPrice)) {
> 	        throw new IllegalArgumentException(
> 	            "bad price: " + unitPrice);
> 	    }
> 	    if (unitPrice != this.unitPrice) {
> 	        this.unitPrice = unitPrice;
> 	        fireChangeEvent(this, PRICE_CHANGED);
> 	    }
> 	}

> ?  Is "something like Lombok" smart enough to auto-generate such code?
> Smart enough to auto-generate without being prompted by annotations
> bulkier than the code itself?

No, this entire subthread is about 'default' getters and setters (otherwise
referred to as 'boiler plate'). Although your use case seems generic enough
that I would be surprised if there wasn't something along those lines out
there.

Liebe Gruesse,
		Joerg

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

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

#38923

On Tuesday, April 16, 2019 at 4:46:33 PM UTC-4, Eric Sosman wrote:
>      What is wrong (tm) with
> 
> 	public void setUnitPrice(double unitPrice) {
> 	    if (unitPrice <= 0 || !Double.isFinite(unitPrice)) {
> 	        throw new IllegalArgumentException(
> 	            "bad price: " + unitPrice);
> 	    }
> 	    if (unitPrice != this.unitPrice) {
> 	        this.unitPrice = unitPrice;
> 	        fireChangeEvent(this, PRICE_CHANGED);
> 	    }
> 	}
> 

If you leave off the validation and just declare class variable public double unitPrice, you either validate it where it gets used or never validate assuming it's ok to just throw an error where it would be used if it somehow gets an invalid value.

If you would have a number of variables that you want the same exact validation you could build in a private method:
public void setUnitPrice(double unitPrice) {
  setPositiveValue(values.UNITPRICE,unitPrice);
}
(where UNITPRICE is an enum) ?

or you could just use generated code, with a UI (IDE) or Eclipse plugin type thing.
We do use several languages at my company and one of them we did write our own custom IDE (in C#) which inserts certain common code blocks which have to be in every program but would be tedious to write.

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

#38926

On 2019-04-17 15:42, Eric Douglas wrote:
> On Tuesday, April 16, 2019 at 4:46:33 PM UTC-4, Eric Sosman wrote:
>>      What is wrong (tm) with
>>
>> 	public void setUnitPrice(double unitPrice) {
>> 	    if (unitPrice <= 0 || !Double.isFinite(unitPrice)) {
>> 	        throw new IllegalArgumentException(
>> 	            "bad price: " + unitPrice);
>> 	    }
>> 	    if (unitPrice != this.unitPrice) {
>> 	        this.unitPrice = unitPrice;
>> 	        fireChangeEvent(this, PRICE_CHANGED);
>> 	    }
>> 	}
>>
> 
> If you leave off the validation and just declare class variable public double unitPrice, you either validate it where it gets used or never validate assuming it's ok to just throw an error where it would be used if it somehow gets an invalid value.

That has to be the worst advice I've read in quite a while.

-- 
DF.

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

#38927

On Wednesday, April 17, 2019 at 3:36:33 PM UTC-4, Daniele Futtorovic wrote:
> > If you leave off the validation and just declare class variable public double unitPrice, you either validate it where it gets used or never validate assuming it's ok to just throw an error where it would be used if it somehow gets an invalid value.
> 
> That has to be the worst advice I've read in quite a while.
> 
> -- 
> DF.

I would agree that's probably not a good idea, but I'm sure I've seen it done..

Personally I think option 2 sounds better.. preferably use an IDE or plugin that can create getters and setters for you and do the validating for you if there are multiple fields with the same validation requirement.  If not then just build in a framework for it, try to prevent duplicating code as much as possible.

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

#38929

On Wed, 17 Apr 2019 14:05:46 -0700 (PDT), Eric Douglas wrote:

> On Wednesday, April 17, 2019 at 3:36:33 PM UTC-4, Daniele Futtorovic wrote:
>>> If you leave off the validation and just declare class variable public double unitPrice, you either validate it where it gets used or never validate assuming it's ok to just throw an error where it would be used if it somehow gets an invalid value.
>> That has to be the worst advice I've read in quite a while.
> I would agree that's probably not a good idea, but I'm sure I've seen it done..

I've seen people store passwords in plain text and compare strigns with ==.
Having seen something done isn't really an argument for anything :|

> Personally I think option 2 sounds better.. preferably use an IDE or plugin that can create getters and setters for you and do the validating for you if there are multiple fields with the same validation requirement.  If not then just build in a framework for it, try to prevent duplicating code as much as possible.

I like the Lombok way, because that way, the code for "empty" getters and
setters, as in the ones that just do nothing beyond setting and getting,
are completely hidden from the code. Imagine a class such as:

@Data
public class SomeItem {
	private String name;
	private LocalDateTime creation;
	private int amount;
	
	public void setAmount(int amount) {
		if (amount <= 0) throw new IllegalArgumentException("...");
		
		this.amount = amount;
	}
}

With a single glance you see immediately the only code in the class that
does anything of relevance - it isn't burried between the other 5 getters
and setters.

Liebe Gruesse,
		Joerg

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

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web