› ›

Good or bad: accessing object variables directly

MoxlMoxl
edited February 2017 in Programming Questions

Hi, I have a question about general practice. When accessing variables in objects, is it bad practice to access them directly (object.variable) compared to creating get methods to access them (object.getVariable())? How do both techniques differ and how can it affect the quality or maintenance of a program?

Tagged:

Best Answers

Answers

  • koogskoogs
    Answer ✓

    Getters that just return the value are a waste of lines a lot of the time, especially in an editor where you have to type them yourself (unlike netbeans or eclipse which will generate then for you).

    This sounds like homework. And the above is not an answer that the homework setter would like. But processing is looser than Java - the programs are not called sketches for no reason.

  • jeremydouglassjeremydouglass
    edited February 2017 Answer ✓

    @Moxl --

    Arguments in OO languages like Java have gone on for a very long time about whether getters and setters (accessors and mutators) are good, bad, necessary when compared with direct variable manipulation, or evil when compared to 'pure' encapsulating methods etc. If you search Google or StackOverflow you will find many passionate position pieces in many directions. Most of the arguments both for and against getters and setters describe standards for code maintainability in enterprise projects that already have or will someday have many thousands of lines of code and/or multiple programmers / users -- this may not fit your situation while writing a Processing sketch! For a classic example of this kind of discussion see the Data Abstraction section of this article, and the follow-up:

    As @koogs mentions: If you are taking a computer science course that is teaching a particular paradigm of software development for future professional behavior then your answer depends on what you learned in that context.

    However: If you are trying to adopt a style for personal projects and aren't doing "enterprise" programming then you can make more pragmatic decisions -- or be inconsistent on a sketch-by-sketch basis.

    Often when working within the context of a lot of other code it is helpful to write in the same style as that library / framework -- if it uses lots of getters and setters, use them, if it doesn't, don't.

    What does the Processing reference show and what does the core library do? I think Processing takes a pragmatic mixed approach -- there is no one right way.

    Processing Get/Set Examples

    Lots of common functions in Processing seem to be setters, although many don't have corresponding getters or the get method is a variable.

    1. set the text size with textSize(x) -- not textSize=x
      ...but there is no getter or variable to check it; make your own if needed
    2. set the frame rate with frameRate(x) -- not frameRate=x
      ...but check it with frameRate -- not getFrameRate()

    Sometimes there are both setters AND direct access. For a mixed example loop() and noLoop() are used to set true/false on a looping variable -- which you could also set directly, although this isn't documented in the reference.

    In this case the reference doesn't suggest a variable or a getter to check looping status, but both looping and isLooping() are accessible, if undocumented. Or you can create your own check.

    For another type of mixed example, the main surface pixels array and PImage both have set() and get(), OR you can interact directly with the pixels[] array data -- however you must call loadPixels() and updatePixels() before and after direct access to do so safely.

    Other common Processing objects / classes may offer primarily one form or the other. On the one hand, PShape and PImage each have lots of "setFoo()" and "getFoo()" type methods...

    ...and on the other hand, PVector has fields x,y,z. These are accessed directly; there aren't getters and setters for them (no x(), getX(), or setX()). This makes vector-heavy code more concise to write and read.

  • MoxlMoxl

    Thanks, very nice reply. Now I know I do not need to bother writing getters and setters.

  • ChrisirChrisir
    edited February 2017

    True.

    But using a lot of properties of an object outside the class can be a sign of badly written code.

    Look here:

    vorratsfeldLinks[i].x = vorratsfeldLinks[i].xOriginal;
vorratsfeldLinks[i].y = vorratsfeldLinks[i].yOriginal;

    as we can see, there is a lot going on with properties inside the class.

    Always when this occurs, it might be time to transfer more functionality inside the class:

        vorratsfeldLinks[i].setBackToOriginalPosition();
  • MoxlMoxl

    Yes, this makes sense. Objects should "take care of themselves".

  • ChrisirChrisir

    exactly.

  • koogskoogs

    the time to use getters are places where it's not possible to just set a single value - fill colour, for instance, depends on colorMode. you can also specify it using greyscale, #facade style, rgb ints etc. a getter lets you use useful polymorphism, which is quite powerful.

    (ok, a few more than that even

    fill(rgb)
fill(rgb, alpha)
fill(gray)
fill(gray, alpha)
fill(v1, v2, v3)
fill(v1, v2, v3, alpha)

    )

    processing core also, i reckon, uses getters because methods are easier to document than fields 8)

  • GoToLoopGoToLoop

    I would only bother to write setters for a class when I need to mutate more than 1 field at once. (:|

  • Lord_of_the_GalaxyLord_of_the_Galaxy

    @GoToLoop same here, only I am even worse off - I only write setters if they must take in a single variable and change many more in turn.
    And getters are mostly useless, unless you're doing a project for someone else, or must make the variable private/protected. (For example say you have a variable in your class that must be accessed by other classes, yet you cannot allow them to modify the variable)

  • Lord_of_the_GalaxyLord_of_the_Galaxy

    @koogs I agree with you too.

Sign In or Register to comment.