Accessing class member variables - properties or variables?

Discussion in 'Java' started by dwok, Mar 3, 2005.

  1. dwok

    dwok Guest

    I have been wondering this for a while now. Suppose I have a class
    that contains some private member variables. How should I access the
    variables throughout the class? Should I use properties that expose the
    variables or is it OK to just access the variables directly? Keep in
    mind that I am talking about accessing the variables from within the
    class that they are defined. Thanks!
    dwok, Mar 3, 2005
    #1
    1. Advertising

  2. dwok

    Guest

    Regardless of what level of access you give an instance variable, it
    can be accessed in any instance method in the class definition.
    , Mar 3, 2005
    #2
    1. Advertising

  3. Hi,

    I would access the variables directly from within the class. Use
    properties for accessing them from outside the class.

    Ken
    -----------------
    "dwok" <> wrote in message
    news:...
    I have been wondering this for a while now. Suppose I have a class
    that contains some private member variables. How should I access the
    variables throughout the class? Should I use properties that expose the
    variables or is it OK to just access the variables directly? Keep in
    mind that I am talking about accessing the variables from within the
    class that they are defined. Thanks!
    Ken Tucker [MVP], Mar 3, 2005
    #3
  4. "dwok" <> schrieb:
    > I have been wondering this for a while now. Suppose I have a class
    > that contains some private member variables. How should I access the
    > variables throughout the class? Should I use properties that expose the
    > variables or is it OK to just access the variables directly? Keep in
    > mind that I am talking about accessing the variables from within the
    > class that they are defined.


    I think this is the way most developers do it.

    Nevertheless, I use 'Static' [VB.NET] variables inside methods whenever it
    makes sense to use them, and I never access member variables which are
    holding property values directly, except in the property's 'Get' or 'Set'
    block.

    --
    M S Herfried K. Wagner
    M V P <URL:http://dotnet.mvps.org/>
    V B <URL:http://dotnet.mvps.org/dotnet/faqs/>
    Herfried K. Wagner [MVP], Mar 3, 2005
    #4
  5. dwok

    Hal Rosser Guest

    "dwok" <> wrote in message
    news:...
    > I have been wondering this for a while now. Suppose I have a class
    > that contains some private member variables. How should I access the
    > variables throughout the class? Should I use properties that expose the
    > variables or is it OK to just access the variables directly? Keep in
    > mind that I am talking about accessing the variables from within the
    > class that they are defined. Thanks!


    I assume by 'member' variables, you mean 'instance' variables (which can be
    thought of as 'properties' of an instance of the class). <<<as a general
    rule>>> Normally, instance variables are declared private and normally,
    the 'get' and 'set' methods to access them are declared public. individual
    mileage may vary.
    'Static' variables (and constants) belong to the class without regard to any
    instance (VB.NEt's Color.Blue for example).
    Hal Rosser, Mar 3, 2005
    #5
  6. dwok

    Bruce Wood Guest

    It all depends upon the situation.

    For example, I have a class in which setting a property through the
    "set" method causes the class to fire an event saying that the value
    changed. Sometimes, from within the class I want to set it in this way;
    if I forget, any subscribers won't know that the value changed. Other
    times, I definitely want to just set the value, without firing an
    event.

    What I'm driving at here is that properties often do more than just set
    the value of a private member: they do additional processing. This is
    particularly common in WinForms applications in which objects must
    notify the UI that something has changed and needs to be redisplayed.

    In those cases in which a property does nothing more than set the
    member variable, most developers just set the member variable directly.
    Bruce Wood, Mar 3, 2005
    #6
  7. Hal,

    "Hal Rosser" <> schrieb:
    > 'Static' variables (and constants) belong to the class without regard to
    > any
    > instance (VB.NEt's Color.Blue for example).


    In VB.NET, variables marked as 'Static' belong to the method they are
    decalared in:

    \\\
    Private Sub Foo()
    Static x As Integer
    ...
    End Sub
    ///

    Properties like 'Color.Blue' are shared properties ('Shared' modifier).

    --
    M S Herfried K. Wagner
    M V P <URL:http://dotnet.mvps.org/>
    V B <URL:http://dotnet.mvps.org/dotnet/faqs/>
    Herfried K. Wagner [MVP], Mar 3, 2005
    #7
  8. dwok

    Hal Rosser Guest

    "Herfried K. Wagner [MVP]" <> wrote in message
    news:...
    > Hal,
    >
    > "Hal Rosser" <> schrieb:
    > > 'Static' variables (and constants) belong to the class without regard to
    > > any
    > > instance (VB.NEt's Color.Blue for example).

    >
    > In VB.NET, variables marked as 'Static' belong to the method they are
    > decalared in:
    >
    > \\\
    > Private Sub Foo()
    > Static x As Integer
    > ...
    > End Sub
    > ///
    >
    > Properties like 'Color.Blue' are shared properties ('Shared' modifier).


    Oh YEAH! you're right! I should not have inserted a reference from VB, since
    I was answering the OP in terms of Java. - In VB, 'static' refers to a
    variable that keeps its value from call to call - and is really not
    applicable in the context of this thread. I was answering the OP in terms of
    Java (but foolishly inserted a VB reference - ie: Color.Blue )
    In Java - the Color.Blue reference analogy would be referring to a variable
    named "Blue" which was declared "static" in the class named "Color". Hence
    the ability to reference "Blue" without creating an instance of the "Color"
    class.
    Hal Rosser, Mar 4, 2005
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. E11
    Replies:
    1
    Views:
    4,708
    Thomas Weidenfeller
    Oct 12, 2005
  2. Steven T. Hatton
    Replies:
    2
    Views:
    400
    tom_usenet
    Aug 16, 2004
  3. Siemel Naran
    Replies:
    4
    Views:
    785
    Micah Cowan
    Jan 12, 2005
  4. Replies:
    9
    Views:
    924
  5. Replies:
    0
    Views:
    157
Loading...

Share This Page