February 12, 2004

Getters and setters are here to stay

Getters and setters are not going away. Deal with it.

Don't believe what wannabe pundits and OO purists tell you. At the end of the day, every object becomes a primitive type.

Unfortunately, Java doesn't have the prettiest way to handle getters and setters, which leads up to a lot of code obfuscation. Granted, we are now very much used to visually identify the pattern:

  private String m_firstName;
  public String getFirstName() {
    return m_firstName;
  }
  public void setFirstName(String fn) {
    m_firstName = fn;
  }

  private Integer m_socialSecurityNumber;
  public Integer getFirstName() {
    return m_socialSecurityNumber;
  }

Note that in the above example, I declared the field right next to its getters and setters, which improves readability and locality, in my opinion, but it's a technique that is pretty much never used, making it even harder to find which fields are exposed with getters and setters and which ones are stricly part of the private implementation of the class.

Compare this to the terse but to-the-point pseudo-code:

  property String name;
  property readonly Integer socialSecurityNumber;

In order to support the most flexibility for attributes, a language needs to offer the three functionalities. Here is how Ruby, C# and Java address these three problems:

Java Ruby C#
Concise notation for read-write attributes N/A attr_accessor :first_name public string FirstName {
  get; set;
}
Concise notation for read-only attributes N/A attr_reader :first_name public string FirstName { get; }
Full definition of accessors for additional logic public String getFirstName() {
  /* code */
}
public void setFirstName(String s ) {
  /* code */
}

def first_name
  /* code */
end
def first_name=
 /* code */
end
public string FirstName {
  get {/* code */}
  set { /* code */}
}

Note that another important feature supported by both Ruby and C# -- but unfortunately not Java -- is that of "Universal Access". Regardless of how you choose to define your properties, they all end up going through the same code line when executed. In other words, you can start by define "attr_accessor first_name" and then later use more complex logic by defining "def first_name=". In either cases, assigning this attribute will always end up calling the assignment method.

It's too bad that properties didn't make it in Tiger.

Posted by cedric at February 12, 2004 05:45 PM
Comments

Big deal... Adding property keywords is not a big deal. Any decent ide will automatically generate default getters and setters. Also, those keywords won't help at all when you need to do something more than just retrieve or set the value of something.

I think it's much more readable to have all the local variables at the top of the class. To each his/her own though...

Posted by: No one at February 12, 2004 11:35 AM

I guess there's two ways of looking at the top/bottom variable placement. If you go in to figure out the implementation, it's easier if the instance variables are right there on the top. Then again, if the intent is to see what the class can do for you, the instance variables are simply clutter to scroll past. And then there's all those static variables...

Posted by: Lasse at February 12, 2004 11:40 AM

All what static variables?

All I do is type objectname. and I get a drop down list of all the methods. Pretty simple.

I guess I over estimate the number of people that use a decent IDE. Those that don't want to add all kinds of typing shortcuts.

Posted by: No one at February 12, 2004 11:48 AM

"the instance variables are simply clutter to scroll past"

Even so, I'd rather have my clutter all in one place than scattered around in my code.

I think there is precedent for keeping them all in one place. Look a little bit higher...you know...all those lines that start with "import". You can't think that the code would look better if those were scattered all about, too...

Posted by: inignot at February 12, 2004 12:02 PM

I don't have any issues with properties, but I do have issues with code that simply takes all the data out of one class and does something with it in another--when quite often that logic makes more sense to be encapsulated within the class itself.

Posted by: kdonald at February 12, 2004 01:45 PM

We don't need them! Sure, in some cases we would get a bit terser and simpler syntax, even though the C# syntax is just awful, IMNSHO. The biggest problem is that it introduces yet another way of doing things, which we don't need. One more thing to learn, and god knows there's enough of them. The beauty with Java is that it is such a simple language, but with just about all orthogonal features to allow us to span just about any coding universe.

Posted by: Mats Henricson at February 13, 2004 02:23 AM

I think it's important to distinguish between the syntax for accessing properties and the syntax for defining them.

For accessing properties is person.firstName("Fred"); so much different from person.firstName = "Fred";. Not much in it as far as I am concerned, although the first looks like any other method call.

For defining implementation, I don't see there's any real problem as things stand. Perhaps it'd be nice to sort remove duplication in the JavaDocs. I don't think non-encapsulation should be encouraged. A public variable is still a public variable even if you call it a property.

Posted by: Tom Hawtin at February 13, 2004 12:08 PM

FWIW in Groovy we went with the convention that you shouldn't use public/protected fields and should use properties instead.

So by default declaring what looks like a public field will create getters/setters - unless you declare an explicit getter/setter method (to change visibility or add a custom implementation etc)

e.g.

class SomeBean {
String name
Integer id

// make setter read only
private void setId(Integer value) {...}
}

So far it seems a reasonable compromise in that common beans are quick and easy to write and there's no wierd new syntax for properties

Posted by: James Strachan at February 16, 2004 12:45 AM

FWIW, C# like Java does not have a concise notation for attributes. The example syntax in the table can be used only to impose accessibility constraints on abstract or interface properties.

Posted by: Sven Kuenzler at February 16, 2004 02:33 AM

I think you missed the point of the "wannabe pundit's" article. Basically, the author was saying to limit providing accessors as much as possible to improve encapsulation.

Nowhere in the article does the author suggest getting rid of getters and setters from the Java language, in fact he admits that there are times they are unavoidable.

Posted by: George Coller at February 17, 2004 04:03 PM

There will always be those cases where you do want getters and setters. Having a more concise notation to generate them is just fine as long as the concise notation is explicitly defined to be syntactic sugar that means "define this method and that method", so that you don't have to introduce a whole new concept into your language called "properties" and have to hair up your language spec to explain how "properties" interact with everything else, and hair up your meta-object-protocol/reflection-facility to add a whole new thing called "properties" etc.

And if you will pardon my going into old-fogie mode: we did this all properly in Flavors in 1979,
and later in CLOS (Common Lisp Object System).

Posted by: Dan Weinreb at February 18, 2004 11:39 PM

Having done few months of C# programming in Visual Studio I've found that, whatever the theory, properties are very helpful practically. Whenever I have to add a property to a class, I wince at the trouble (always feeling tempted to just declare the attribute public) but I wince less at the bother that comes with the C# syntax than Java. I agree with Anders Hejlsbergs argument that the language should support the things we do most frequently.

When I am browsing code with intellisense, I find the visual distinction made between properties and attributes is most helpful.

Posted by: Stephen Hosking at April 11, 2006 05:21 PM

I couldn't help but notice that the SSN getter returns the first name.

Posted by: foo at April 21, 2006 01:08 PM

effozhxc http://bhkhsmkg.com otjopvnz qzibbirc [URL=http://tbthkmyp.com]akhaixfo[/URL] aggvhmdv

Posted by: lhbyqsph at July 2, 2007 11:17 PM

mffoqndl [URL=http://qjqthogz.com]algiqsna[/URL] gdgpllaj http://wyfjgovr.com slojjmlp hjahsyju

Posted by: dkpxybeh at July 2, 2007 11:19 PM

wukslsfa [URL=http://lbzgkrfu.com]ukcuxerk[/URL] tmxvmjdy http://xfkmatif.com frceixbs npyulpms

Posted by: kzmjwmpn at July 2, 2007 11:20 PM

IT WOULD HAVE BEEN MORE HELPFUL TO DISPLAY A FULL SAMPLE CODE ALONG WITH THE MAIN FUNCTION.IT WILL HELP THE BEGINNERS.

Posted by: SAYAN BHATTACHARYA at January 22, 2009 01:25 AM
Post a comment






Remember personal info?