• Post Reply Bookmark Topic Watch Topic
  • New Topic

Coding Style: accessor vs. attribute  RSS feed

 
JD Glanville
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Silly question time �
I�m having a discussion with a coworker concerning the use of attributes vs accessors( methods ). I prefer using accessor methods to retrieve information, whereas he prefers to open the scope of the attribute so that other classes can access the attribute directly.
For example, I prefer:

Whereas, he prefers:

The arguments that I�ve been able to make so far are:
  • I can ensure instantiation (lazy or otherwise)
  • I can prevent modification (through the lack of a setter method)
  • basic data encapsulation (he considers this a week argument, but that�s another argument)


  • However, I am not a convincing debater.
    Can anyone provide other pros and cons to these different styles?
    Can anyone point to respected references (Eckel, Joy, Dijkstra, Fowler, Gamma, etc.) showing that they think one style is better then the other for the reason ...? (My coworker may not believe my arguments, but he might be more susceptible to others arguments.)
    Thanks
    JDG
     
    Joe Ess
    Bartender
    Posts: 9439
    12
    Linux Mac OS X Windows
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Originally posted by JD Glanville:

    Can anyone provide other pros and cons to these different styles?

    You can't synchronize access to an attribute. Race conditions will abound in non-trivial applications.
    You can't disguise the underlying implementation if you are exposing these details. Let's say you are implementing a java.util.List and you leave the size attribute public. What's to stop a programmer from setting size = 0 and leaving your class in an undetermined state? There would be no control given to your class to free resources and re-initalize beginning and end pointers.


    Can anyone point to respected references (Eckel, Joy, Dijkstra, Fowler,

    How about the Java API? Every non-trivial class (i.e. java.awt.Rectangle is a counter example) uses accessors to the exclusion of public attributes.
     
    Michael Fitzmaurice
    Ranch Hand
    Posts: 168
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi JD
    In short, your colleague is undertaking a very bad practice - exposing the implementation of his classes as opposed to the interface. He seems to dismiss encapsulation as a non-issue - amazing. This leads to a high level of coupling between classes, which is always to be avoided. Using your colleague's idea, let's say I decide to rename one of my class members - I have potentially just broken every single piece of code that uses my class, and they are broken because they have an unacceptably high dependence on the internal implementation details of my class.
    How my class does what it does is nobody else's business, and that 'how' includes the number of, type of, and name of any member variables.If your colleague does not think this is important, why use OO languages at all? Everyone is entitled to their own opinion, but I feel he really is fighting a losing battle on this one. Encapsulation is one of the most fundamental tenets of OO programming.
    BTW, I have never yet read a Java coding standard that allows your friend's style of programming, let alone encourages it.
    Michael
    [ October 30, 2003: Message edited by: Michael Fitzmaurice ]
    [ October 30, 2003: Message edited by: Michael Fitzmaurice ]
     
    fred rosenberger
    lowercase baba
    Bartender
    Posts: 12563
    49
    Chrome Java Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    i don't know how valid this is, but here's my thoughts...
    when i was first learning OO, i felt the same way as your colleage. i kept thinking "who cares if i can see the members - i wrote it, i know whats there, i know if i change stuff, etc etc etc".
    it wasn't until i started working for a large company, where i had to use not only objects people in my company wrote, but third-party stuff we bought and used for whatever reason.
    i quickly learned (and was told) everything poeple have been saying here. if i spent 6 months writing code that used a third party class, directly manipulating the data, i'd be pretty p****d if they changed it. which is something they are entitled to do (and DID do).
    One of the big things i've learned in programming is to Cover Your A**. if you let people into your classes, you have NO idea if data is EVER valid, safe, correct, or even THERE anymore. How can you garantee your object is safe if you have no control over it's pieces?
    sorry for the rambling...
    f
     
    Jim Yingst
    Wanderer
    Sheriff
    Posts: 18671
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    BTW, I have never yet read a Java coding standard that allows your friend's style of programming, let alone encourages it
    Well, there's always Sun's Code Conventions for the Java™ Programming Language. The second paragraph of 10.1 allows and encourages this programming style in certain circumstances. I would say that if a class has any behavior at all, that is, any methods other than get/set, then it can't be considered just a data structure, and none of its mutable and/or instance data should be public. Only really, realy boring classes should have public data rather than accessors. Personally I only do it for nested classes which aren't public anyway. Often for a nested class, I'd prefer to keep the definition as short and simple as possible, and eliminating accessors may help that goal. But if the API of a class is exposed above package level, it's usually worthwhile to take a little extra time to declare accessors and mutators, even if they don't seem necessary at first.
    A few more arguments in favor of accessors and mutators: It's easier to add logging later if you find you need it. Or if you want to search for places in the code where a fields is modified (not just read) it's easier to search for "setFoo(" rather than search all references to "foo". You can also control access more finely, e.g. perhaps read access to a veriable is public, but write access is protected. (Without mutators, your only option to differentiate read from write is by making a variable final.) Using get/set also lets you insert defensive copying of mutable data, if you find that useful/necessary to your application.
    [ October 30, 2003: Message edited by: Jim Yingst ]
     
    Michael Fitzmaurice
    Ranch Hand
    Posts: 168
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Jim
    I stand corrected, but feel obliged to point out how highly dependent on particular circumstances this caveat is, and even then I don't know if I would go so far as to say it is encouraged. Accepted, yes. And I would say the caveats you provided are actually more valuable than those Sun offer (i.e. 'if you would have used a struct, its okay').
    However, I am really talking about what the default practice should be for public classes, which is what I guessed was under discussion in this thread. I feel strongly enough about that to re-iterate my objection to the practice of matter-of-factly declaring member variables public as a habit. I regard this as a completely filthy practice, and would be amazed to find that anyone had written a coding standard that encouraged this as the norm. And if I was ever asked to conform to such a standard, I would really have to ask myself if I wanted to work on a project like that.
    I know we are all in agreement that JD's preference is superior, hence this further post is possibly a bit redundant, but sometimes a fella just has to get something off his chest...
     
    It is sorta covered in the JavaRanch Style Guide.
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!