2 ms·
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. T
by 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 agoAn 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