6 ms·

They do allow code generation, and that's precisely the problem. You end up with these ridiculously bloated files, most of the code of which hasn't ever even be

by lukev 14y ago

They do allow code generation, and that's precisely the problem. You end up with these ridiculously bloated files, most of the code of which hasn't ever even been looked at by a human. But generating getters and setters based on fields is putting the cart before the horse. You're right, it is very important for your classes to have a stable, clean public API that's distinct from the private implementation. But if that public API is intended to expose data at the field level, then just expose the fields without confusing the issue. If you don't want to expose the fields, then don't. Having private-but-not-really fields with a lot of auto-generated getters and setters doesn't help you provide a clean, small API: instead, it bloats the public API. Also, it obfuscates what's actually happening... is a getter just a simple data value, or is it doing a bunch of complicated shit behind the scenes? And if it is doing a bunch of complicated shit, just make it a regular method on the public API, not a getter that's logically tied to a field that the client knows is there. TL;DR: Fields are fields, methods are methods, auto-generating getters/setters blurs the line in unhelpful ways.

danieldk 14y ago
Except when you want to change behavior in the future, e.g. adding a check to the getter or doing more than simply setting a value in the setter. If you started out with getters/setters in the first place, you can do this without changing the API and ABI.
- nikolavp 14y ago
  Well if you are changing the behaviour of the getter or the setter then you are already changing the public API contract. I would rather want a compile time error instead of a silently not changing value in a setter for example after a library upgrade
  - delinka 14y ago
    Changing the underlying implementation is not changing the API contract. The API makes no guarantees about where your arguments are shipped off to nor where the return value came from. It simply says "you give me X, Y, Z and I'll return you M" and that's it. This is the very reason for specified APIs: the underlying implementation changes (for caching, efficiency, new storage models, etc) and external code goes on its merry way doing what it did before-- running.
jpatte 14y ago
if that public API is intended to expose data at the field level > That doesn't make a lot of sense. An API is an interface, which in this case exposes data. The fact that this data is held by objects at the field level as nothing to do with the purpose of the API: it's an implementation concern. The consumers of this API do not, and should not, need to know whether a field or anything else is used to provide the requested data. If the public API gets bloated when using getters/setters then blame Java, not this basic encapsulation principle. is a getter just a simple data value, or is it doing a bunch of complicated shit behind the scenes? > As you said, and as a rule of thumb, never do a bunch of complicated shit inside a getter: always expose a method for this operation. Just because getters exist does not mean methods should disappear.
- lukev 14y ago
  An API is an interface, which in this case exposes data. Yes. The confusion comes from complecting[1] an object api and data. In general, having a class that is both a data structure (a bean or a struct) and a service class is a bad idea. My contention is that if a class is Just Data, exposing public fields is fine. And if it is a service class that needs a consistent, stable API, it shouldn't be exposing fields via getters and setters either. [1]http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy
nl 14y ago
TL;DR: Fields are fields, methods are methods, auto-generating getters/setters blurs the line in unhelpful ways. That's not really true in Java. The getter/setter pattern is baked into a lot of the standard Java libraries. For example, Javabeans are: a Java Object that is serializable, has a 0-argument constructor, and allows access to properties using getter and setter methods.[1] Things like JPA, Jersey, Guice etc all rely on the Javabeans convention. Yes, Java should have real properties like Object Pascal & C# does, but it doesn't, and getters & setters are harmless to anything except aesthetic sensibilities. TL;DR: Getters & setters are a useful convention that allow many things that are not possible with public fields. [1] http://en.wikipedia.org/wiki/JavaBeans http://en.wikipedia.org/wiki/JavaBeans

by lukev 14y ago

danieldk 14y ago

Except when you want to change behavior in the future, e.g. adding a check to the getter or doing more than simply setting a value in the setter. If you started out with getters/setters in the first place, you can do this without changing the API and ABI.

nikolavp 14y ago
Well if you are changing the behaviour of the getter or the setter then you are already changing the public API contract. I would rather want a compile time error instead of a silently not changing value in a setter for example after a library upgrade
- delinka 14y ago
  Changing the underlying implementation is not changing the API contract. The API makes no guarantees about where your arguments are shipped off to nor where the return value came from. It simply says "you give me X, Y, Z and I'll return you M" and that's it. This is the very reason for specified APIs: the underlying implementation changes (for caching, efficiency, new storage models, etc) and external code goes on its merry way doing what it did before-- running.

jpatte 14y ago

if that public API is intended to expose data at the field level > That doesn't make a lot of sense. An API is an interface, which in this case exposes data. The fact that this data is held by objects at the field level as nothing to do with the purpose of the API: it's an implementation concern. The consumers of this API do not, and should not, need to know whether a field or anything else is used to provide the requested data. If the public API gets bloated when using getters/setters then blame Java, not this basic encapsulation principle. is a getter just a simple data value, or is it doing a bunch of complicated shit behind the scenes? > As you said, and as a rule of thumb, never do a bunch of complicated shit inside a getter: always expose a method for this operation. Just because getters exist does not mean methods should disappear.

lukev 14y ago
An API is an interface, which in this case exposes data. Yes. The confusion comes from complecting[1] an object api and data. In general, having a class that is both a data structure (a bean or a struct) and a service class is a bad idea. My contention is that if a class is Just Data, exposing public fields is fine. And if it is a service class that needs a consistent, stable API, it shouldn't be exposing fields via getters and setters either. [1]http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy

nl 14y ago

TL;DR: Fields are fields, methods are methods, auto-generating getters/setters blurs the line in unhelpful ways. That's not really true in Java. The getter/setter pattern is baked into a lot of the standard Java libraries. For example, Javabeans are: a Java Object that is serializable, has a 0-argument constructor, and allows access to properties using getter and setter methods.[1] Things like JPA, Jersey, Guice etc all rely on the Javabeans convention. Yes, Java should have real properties like Object Pascal & C# does, but it doesn't, and getters & setters are harmless to anything except aesthetic sensibilities. TL;DR: Getters & setters are a useful convention that allow many things that are not possible with public fields. [1] http://en.wikipedia.org/wiki/JavaBeans http://en.wikipedia.org/wiki/JavaBeans