Avoid getters and setters whenever possible

I have trouble articulating this point, but I never understood the argument why you’d want getters or setters at all.

From my point of view, your data structures are your API. Attempting to hide them behind methods so that you can do something clever doesn’t work when it’s not always you that constructs the data (I’m thinking of things like json deserialization and accepting data from outside your control.).

All the arguments behind getters and setters seem rooted in this fear that maybe you’ll change your mind later about your data, but somehow you won’t have to change the function signatures of your getters/setters when that happens... this seems so contrived to me it’s insane to design entire frameworks and paradigms with this as a central idea.

Maybe I’ve been using Go for a bit too long now but I really think the mixing of data and logic is a fundamental mistake.

This is strange advice. There's no real drawback from using getter/setter and there are obvious benefits.

And even if you mostly use public properties, there will still be cases where you'll need getter/setter so you'll end up with a messy mix of getter/setter and public properties. Better be consistent and always use getter/setter.

For Java exists the Project Lombok, it works pretty well for this purpose, you can use getters and setters without polluting the code with auto-generated stuff. Have some other cool features like fluent accessors, builders, auto cleanups for close() and plugins for IDEs. IMHO every Java programmer should check it out.

I disagree with the author, getters and setters are a good tool to have and used in the right place.

Setters are great when you want to do some validation and add an entry in a log when the setter is used.

There are rules what not to do in getters or in setters so if you use does practices you are ok.

Overlooked is how they became so ubiquitous: JavaBeans. It was well-meant, but it's left a lot of unintended pain in its wake (I'm looking at you, JPA constructors). Without that standard, Java code might feel quite differently today.

While you can avoid making it worse with idioms like only using constructor injection, you can't unwrite the billions of lines written to date.

Kotlin makes a great effort to atone for the sins of the past.

To me, objects is a data abstraction technique which is about abstracting the said data under a set of operations known as the interface; You are no more thinking about the data but about the operations which then allows all kind of interface abstraction techniques known as design patterns. Once you break that abstraction, you break everything which is relying on.

Even for small classes where there is no design pattern involved, it is important to think about the interface first then the data. take for example, a rectangle, you may think (g/s)etters would be pointless and be tempted to do

  class Rectangle:
    public x, y, w, h;
    
    public Rectangle(x, y, w, h):
      this.x = x;
      ...

Then you need the area

  class Rectangle:
    ...
    public area():
      return w * h;

Then you need to cache the area

  class Rectangle:
    public x, y, w, h, cached_area;

    public Rectangle(w, h):
      this.w = w;
      this.h = h;
      cached_area = w * h;

    public area():
      return cached_area;

Problem here is that w and h being public, user can corrupt the area, you now need to rely on (s/g)etters.

  class rectangle
    ...
    private w;
  
    public setWidth(w):
      this.w = w;
      updateArea();
      
    private updateArea():
      cached_area = w * h;

If you had start with an interface only having operations, you would never had that problem.

  interface Rectangle:
    getX();
    setX(x);
    getWidth();
    setWidth(w);
    area();
    ...

  // implementations are irrelevant to the user.
  class RectangleCached implements Rectangle:
    ...

  class RectangleLazy implements Rectangle:
    ...

  class RectangleWhatever implements Rectangle:
    ...

One of the great leaps in OO is to be able to answer the question "How does this work?" with "I don't care" (Alan Knight)

Note that another solution in this case would be immutability but this is another discussion.

The argument for getters and setters is much stronger when you're writing libraries that are dependencies for projects you don't control.

If you own all consumers of your code, and it's all part of the same project, then you can safely refactor from field access to getters and setters if and when you need to add extra semantics. If you own the consumers but they're not all part of the same project, you can refactor but it will take longer and be a multi-step exercise.

If you don't own the consumers, then you need to break compatibility, which means major version bumps, which will leave some downstream consumers on older versions, and will probably increase version divergence in your userbase, fragmenting the ecosystem and increasing your support load.

The first point:

> (...) My question is how often has the working programmer ever had to do that? I don't remember ever doing this in all my years of software.

has that hollow ring of "I write my software the way it doesn't allow easy changes, so I don't do them, so there's no reason to do it." ... there probably would've been reason to do it more than once, the author just didn't want to do it because it would've been painful.

Anyway: If you can make your class work without exposing anything then go ahead. That's great. But if you have to allow external access a getter will always be better than direct access.

p.s.: Setter means mutable class. Mutable classes are a performance hack. Sometimes you have to do it, most of the time it's premature optimization.

I prefer getters setters over Car1 example especially for large classes. I am quite used to use prefix to filter for methods in IDE - get<thing>, add<thing>, set<thing>, create<thing>, is<thing>, to<thing>, etc. Often you know which one of those subgroups you are interested in and can do ctrl-o or ctrl-space and filter irrelevant options out. The worst option of all is when there are both getters/setters and public fields.

But most importantly, the real practical differences between these styles are minimal for all practical purposes. It is all mostly matter of habit. You might as well argue about which shade of blue is best for syntax highlighting.

Some Java frameworks let class and interface authors use decorators on getters / setters to control how particular class/interface fields are used in some contexts ... e.g., one might have a field (due to an algorithmic consideration) in an entity that's useful when constructing POJOs (plain-old Java objects) that eventually are written to a database, but that particular field should should not be persisted to the database -- one can use decorators to control whether field goes to database, or the data type used to persist the field in the database, etc. It's sometimes useful to treat the getter and setter asymmetrically.

IMHO getters & setters can be a bad smell, symptomatic of classes that are just dumb aggregations of data that have no significant behaviour. I've seen them most often in Java - a single paradigm lang that forces every method or data item to be a class member. And then, because our data item is a class member, it must be encapsulated. Multi paradigm langs offer better approaches to data aggregations. Python, for instance, gives us dictionaries and named tuples as well as classes.

I have sometimes wondered why none of the mainstream OO languages implemented an access class of publicly readable but only privately modifiable.

I prefer actions over getter and setters. The object should take care of itself (ddd style).

But xml and db to object mapper often need them :(

tl;dr: “Don’t use getters and setters” shouldn’t be a goal to strive for. Good OO design should be the goal, and the reduction of getters and setters (and of public data members) is a consequence of that.

I fundamentally agree with the author: Getters and setters often break Tell, don’t ask, increase the public interface of a class (and expose implementation details), and add mutable state, which makes reasoning about the program’s state harder — for getters, this is often mitigated by defensive copying, which has its own set of issues (it can introduce glaring inefficiencies in the code base, which, in many cases, could have been entirely avoided).

The extreme case is when getters and setters lead to quasi-classes [1]. All this is uncontroversial when you think about it (and is backed by a vast consensus in the literature and by what little evidence we have in evidence-based software engineering). On the other hand, I agree with the author that accessors are sometimes a practical solution and shouldn’t be banned entirely.

But I don’t think the author states the case well at all. There’s too much talk about feelings, which is a poor substitute for arguments. This starts with the first example that’s provided: Contrary to what the article claims, there’s of course a difference between `Car1` and `Car2`. Namely, `Car2` can add logic to its accessors without creating introducing API changes. `Car1` cannot do this: If I for instance need to ensure that `engine` is never set to `null` by the user, or I need to add logging, or I need to add deferred loading, etc, I need to make `engine` `private` and add public accessors.

Future-proofing isn’t always relevant but it unfortunately tends to become relevant unexpectedly. Anyway, neither example is probably very good code and, conversely, either piece of code can be appropriate. But they’re emphatically not the same.

I also don’t think the “list of options” at the end is particularly useful because it seems to be a substitute for properly thinking about the architectural design of the code (which doesn’t need to happen up-front, it can happen iteratively): Many accessors are simply never necessary and were instead added “just in case”, or because the programmer thinks about objects as “bags of data” instead of, more appropriately, “[black] boxes with a specific observable behaviour”. This simple change of perspective will drastically reduce the number of public accessors in a code base; but this happens as a side-effect of better OO design, rather than a goal in itself.

[1] http://www.idinews.com/quasiClass.pdf