February 12, 2004Getters and setters are here to stayGetters 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;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;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:
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 PMComments
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... 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 AMAll 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. "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 PMI 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 PMWe 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 AMI 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 PMFWIW 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 { // make setter read only 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 AMFWIW, 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 AMI 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 PMThere 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, 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 PMI couldn't help but notice that the SSN getter returns the first name. effozhxc http://bhkhsmkg.com otjopvnz qzibbirc [URL=http://tbthkmyp.com]akhaixfo[/URL] aggvhmdv Posted by: lhbyqsph at July 2, 2007 11:17 PMmffoqndl [URL=http://qjqthogz.com]algiqsna[/URL] gdgpllaj http://wyfjgovr.com slojjmlp hjahsyju Posted by: dkpxybeh at July 2, 2007 11:19 PMwukslsfa [URL=http://lbzgkrfu.com]ukcuxerk[/URL] tmxvmjdy http://xfkmatif.com frceixbs npyulpms Posted by: kzmjwmpn at July 2, 2007 11:20 PMIT 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 AMPost a comment
|