This discussion is archived
5 Replies Latest reply: Feb 20, 2013 12:15 PM by jschellSomeoneStoleMyAlias RSS

should we always access a field with get methods ?

user11138293 Newbie
Currently Being Moderated
should we always access a field of an instance or object with get, set methods and not directly ? most of the fields I create are to store some information and I don't see any advantage of accessing them through a get method, whats wrong in using a filed directly against get method?
  • 1. Re: should we always access a field with get methods ?
    PhHein Guru Moderator
    Currently Being Moderated
    It depends, if all fields are public, there's no point in using getters and setters. Normally most fields are private and the getters' and setters' access modifyers determine the accessibility of the private fields.
  • 2. Re: should we always access a field with get methods ?
    user11138293 Newbie
    Currently Being Moderated
    why should I make filed private and access it though public get method and not just make field public access it directly?
  • 3. Re: should we always access a field with get methods ?
    PhHein Guru Moderator
    Currently Being Moderated
    Maybe because you want a protected or default getter?
  • 4. Re: should we always access a field with get methods ?
    rp0428 Guru
    Currently Being Moderated
    >
    why should I make filed private and access it though public get method and not just make field public access it directly?
    >
    Because that is what 'encapsulation' is all about and is a fundamental principle of object-oriented programming.

    See the Java Tutorial
    http://docs.oracle.com/javase/tutorial/java/concepts/object.html
    >
    Software objects are conceptually similar to real-world objects: they too consist of state and related behavior. An object stores its state in fields (variables in some programming languages) and exposes its behavior through methods (functions in some programming languages). Methods operate on an object's internal state and serve as the primary mechanism for object-to-object communication. Hiding internal state and requiring all interaction to be performed through an object's methods is known as data encapsulation — a fundamental principle of object-oriented programming.
    >
    See the examples in that section.

    Users should NOT have to know the internal details of how the data is stored in order to be able to use it. For example consider a data item representing temperature. What units should the value be stored in? Kelvin, Centigrade, Fahrenheit? Other?

    Why should your user care, or even know how the value is physically stored. You can easily provide 'getters' to retrieve the data and provide it using any of those units: getKelvinTemp, getCentigradeTemp, etc.

    Those 'getters' can perform any conversion that is needed rather than the user having to do it.
  • 5. Re: should we always access a field with get methods ?
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    user11138293 wrote:
    should we always access a field of an instance or object with get, set methods and not directly ? most of the fields I create are to store some information and I don't see any advantage of accessing them through a get method, whats wrong in using a filed directly against get method?
    I believe term definition might be in order.

    The terms 'getter' and 'setter' (or 'getter/setter') is commonly used to indicate a method whose purpose is to expose a property of a class.

    That is NOT the same as a method whod first three letters are 'get'.

    Now if you are referring to getter/setter from the above then encapsulation means nothing because the getter/setter is explicitly exposing the data type of the property.

    Conversely, from the other posting if you have a method like 'getKelvinTemp' then that is a behavior, not a property. The behavior of the class in that case is to provide the temp in Kelvin. if you want think of the class as actually going to a piece of hardware, retrieving the current temp and then calculating the temp in Kelvin. That is certainly behavior and not exposing data (the class doesn't even have a property.)

    You might find it convenient or necessary to expose the data of a class. If so then you might choose to do it via a getter/setter. However exposing data excessively, regardless of how it is done, either indicates a flawed design (bad objects) or an over-engineered one (the getter/setters are not used.) All things in moderation though since you are unlikely to be able to design a moderately complex system without finding it necessary to expose some data.

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points