2 ms·
That's not really true. Why would you need a getBar() method in Java? public class Foo int bar; public Foo(int initBar) { bar =
by axod 16y ago
That's not really true. Why would you need a getBar() method in Java?
public class Foo
int bar;
public Foo(int initBar) {
bar = initBar;
}
public static void main(String[] args) {
System.out.println(new Foo(42).bar);
}
}
- masklinn 16y ago1. bar's visibility is package local, so your code is already broken, bar is invisible outside its package 2. let's say you solve this conundrum by making the field public 2.1. This piece of code is now frozen solid, you will not be able to ever refactor it (where refactoring is defined as changing implementation without changing behavior) since you can not transparently swap fields and methods in Java 2.2. This piece of code is dead to abstract types, as fields can not be part of interfaces in Java. 2.3. This piece of code is incompatible with Java Beans and will therefore be unusable in e.g. JSP taglibs
- axod 16y agoJSP taglibs? wtf are you talking about. I'm in no way defending the idiocy of 'enterprise java'. and your other points don't really make any sense at all. There is no such thing as 'fozen solid code'. Unless you're interfacing to external libraries etc and have agreed on a specific API, which is unlikely to include "yeah just reference 'bar' directly" unless you're insane.