Timeline for What syntax element do you hate most in a programming language you use frequently?
Current License: CC BY-SA 2.5
19 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 27, 2011 at 13:48 | history | edited | dusan | CC BY-SA 2.5 | Corrected Spoon link |
| Oct 30, 2010 at 16:42 | comment | added | greyfade | @Thorbjørn: In general, when a class needs to hold data, the class' job is to protect that data from outside interference: Its interface exposes only functionality, not data; a setter implies that my class is missing needed functionality (like a function that mutates the stored value) and a getter implies that the class has too much responsibility (someone else should be holding this value). In all other cases, a simple class with no interface and public members is the only reasonable choice (that is, getters and setters are unjustified). | |
| Oct 30, 2010 at 16:36 | comment | added | greyfade | @Thorbjørn: IF I had one class that required access to a specific value held by another class, I would reconsider the design of my classes - I probably did something wrong; perhaps the other class should not be holding this value to begin with. If, on the other hand, it's specific functionality relating to a value that I require, then I'd consider adding this functionality to the other class or a new wrapper class. Very, very painfully rarely have I come across the situation where I needed to expose a value with a getter/setter. More usually, inheritance is the answer. | |
| Oct 29, 2010 at 19:02 | comment | added | user1249 | @greyfade, at SOME point you need to provide a way to let one class access information in another class. If you dislike get/set, how would you do it then? | |
| Oct 29, 2010 at 18:01 | comment | added | greyfade | @Thorbjørn: IMO, if you're using an interface that way, you're using it wrong. An interface should expose no knowledge of data, only an interface to logic. A concrete class should have data, but should not expose knowledge of it. | |
| Oct 28, 2010 at 22:05 | comment | added | user1249 | @configurator, have a look at Go. | |
| Oct 28, 2010 at 22:05 | comment | added | user1249 | @greyfade, you cannot specify public fields in interfaces - hence you must use getters and setters. | |
| Sep 29, 2010 at 6:31 | comment | added | configurator | @SHiNKiROU: Java looks clean? I've never heard that one before! My main gripe with Java is the fact that seemingly simple thing takes dozens of lines of code I need to mentally ignore. | |
| Sep 22, 2010 at 17:00 | comment | added | greyfade | @Bart van Heukelom: I would argue that if you have a setter or a public field at all, it's a sign that your class is doing too much or that it's holding on to information that it shouldn't have. Worse, if your client code is modifying the class' members at such a low level, it's abusing that class. Classes should do only and exactly one thing, and it should abstract all of its state from its interface. No client code should be aware of any portion of that class' state, except to explicitly break the encapsulation. | |
| Sep 22, 2010 at 9:18 | comment | added | Bart van Heukelom | @greyfade I'm not saying you should automatically have getters and setters for all fields, but there are many valid use cases for other code directly setting the value of a field, in which case setters are obviously better than public fields. | |
| Sep 21, 2010 at 3:51 | comment | added | Ming-Tang | Java has no metaprogramming, and that may be the reason Java looks "clean" | |
| Sep 20, 2010 at 15:36 | comment | added | greyfade | @Bart van Heukelom: If it's public, it's wrong. If client code is using a setter, it's wrong. Members should be private unless you've got a very good reason otherwise. | |
| Sep 18, 2010 at 13:22 | comment | added | Adam Byrtek | @greyfade: In theory you might be right, but in practice you're going to need getters and setters, just use them sparsely. You could find a lot of them even in Fowler's books on patterns and refactoring. | |
| Sep 18, 2010 at 10:41 | comment | added | Bart van Heukelom | @greyfade: If it's public, you can't easily change what the setting code does (you'll have to change all code that sets the field from the outside). | |
| Sep 18, 2010 at 5:54 | comment | added | greyfade | Having getters and setters breaks encapsulation. The field might as well be public. Members should be private and should be manipulated sensibly by the class with higher-level logic, not with getters and setters from client code. | |
| Sep 10, 2010 at 19:51 | comment | added | finnw | If you need getters for everything then something is wrong with the client code. | |
| Sep 4, 2010 at 19:13 | comment | added | TheLQ | Once again when code is so verbose that it needs auto generating tools, something is wrong. I'm a NetBeans guy, but it also has the ability to auto generate getters and setters. But Javadoc falls out of syn, it's still verbose, it still clutters javadoc, etc | |
| Sep 4, 2010 at 17:16 | comment | added | HoLyVieR | You can generate the beans easily with Eclipse. Just declare your attributes and go under "Source -> Generate Getters and Setters ...". Since eclipse is commonly used to program in Java, I don't see how "Too much code" and "So annoying a 3rd party had to come up with a plugin to do this easily" are a problem. | |
| Sep 3, 2010 at 1:43 | history | answered | TheLQ | CC BY-SA 2.5 |