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


Groups > comp.lang.java.programmer > #38911

Re: Java variable access

From Eric Sosman <esosman@comcast-dot-net.invalid>
Newsgroups comp.lang.java.programmer
Subject Re: Java variable access
Date 2019-04-12 14:40 -0400
Organization A noiseless patient Spider
Message-ID <q8qm37$qhf$1@dont-email.me> (permalink)
References <109a7224-f392-46c3-bf56-7d8bf2bfb4bf@googlegroups.com> <q8q60r$rcu$1@gioia.aioe.org> <2a9f711b-78f4-483b-a94d-d7bb86434f1f@googlegroups.com> <q8q927$4ua$2@dont-email.me> <e8937b9d-a0fc-45f2-87b5-6cf00338788d@googlegroups.com>

Show all headers | View raw


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.

Back to comp.lang.java.programmer | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

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

csiph-web