3 ms·
No, I disagree. If I need to add a getter/setter so that it does something other than just access a field, I'll add that code at the point I need it. It's not
by axod 17y ago
No, I disagree. If I need to add a getter/setter so that it does something other than just access a field, I'll add that code at the point I need it.
It's not efficient to always use setters/getters, even if the language provides them.
The only sorts of things I find painful in Java is writing a class to do Comparator etc, but the number of times you need to do that can be counted on one hand.
Some people who write Java astonish me with their churning out of toString, equals, hashcode, getters, setters. Checkout a few open source projects and you'll see a whole set of files defining interfaces, then a whole mirror set of source files defining the implementation of that. Which is just ridiculous when there is only 1 implementation of everything. Makes the mind boggle, but often it's an IDE churning out autogenerated code (Does that still count as Java? ;) )
- jrockway 17y agoThis is a good technique for libraries. Decoupling interface and implementation makes flexibility the default. If components only speak an interface to each other, it is easy to substitute them in the future. The problem with Java is that the interfaces are usually useless. Imagine you have a build backend talking to a stoplight (red/green widget). The logical interface is for the builder to emit success or failure, and for the stoplight to internally change that to red or green. But of course, many people decide that the build backend should emit red or green, and that the stoplight widget should display that color. So while the build backend isn't coupled to an implementation in theory ("it just uses the RedOrGreenShowable interface!"), it actually is. Programmers....