Hacker News Reader

Comment by the__alchemist | Hacker News Reader

Structs and classes work fine for that. You don't need getters/setters/inheritance/factories etc.

Getters and setters aren't necessary to OO. They're one OO-compatible way to implement data access control. Inheritance is not about where you store the state, but behavior polymorphism. Factories are also not about where to store state, but about dependency injection. (Arguably they are not the right way to do it but one thing we can say for sure is that they are not there to solve the problem of where to store state.)

Not only are getters/setters not necessary, they actively work against good object orientation. The whole point of OO was to work with things in terms of their _behavior_ and not their _data_. The way OO is taught by creating data-centric classes has misled generations of developers into thinking they understand encapsulation by making a variable private and then providing a getter & setter for it.

I spend a good part of my time training Java developers away from this idea in order to help them make their code more testable and understandable. Queries and Commands are not just pedantic alternate names for Getters and Setters: thinking about objects with respect to what you can ask it to do (Command or Request) and what you can find out from it (Query) significantly improves the code that gets written.

The purpose is ergonomics essentially. Technically you don't need a high level language or even assembly and could work just in machine code with all of the other organizational description of it documented elsewhere.

The real question with all features is "Does it make a given task easier, better, or possible Y/N?" Said question is incredibly vague by design and should differ by situation.

Getters and setters:

1. Are only conventions. Nobody's forcing you to use them.

2. Simplify refactoring.

3. Are a necessary layer of abstraction any time that 'setting' a value requires updating a related value.

#1 and #2 are only a manner of taste and implementation-specific use cases of tooling built on top of a language. #3, however, is absolutely necessary, to avoid entire categories of business logic errors.

Just imagine if updating a string's value required you to also manually update the string's length. How many string-length related bugs do you think that kind of adventure will result in a typical program?

The very concept that you can change a string's value or length is an absurdity. A string is a value. If you want a different string, form one.

I don't say that a string has to be mutable, I am saying that when you assign a value to a string variable, such as during its first (and let's say 'only') initialization, it would be absolutely insane to also have to set the string's length.

Arguing against setters is like arguing that

    String s = "foo";

must also be accompanied with

     s.length = 3;

The two operations make zero sense to be done separately - doing so is just a minefield of bugs. The purpose of a setter is to combine similar inseparable operations together.

A trivial pass-through setter obviously provides ~zero value, but it also carries with it ~zero cost. Any compiler worth its salt will optimize its invocation away.

> I am saying that when you assign a value to a string variable, such as during its first (and let's say 'only') initialization, it would be absolutely insane to also have to set the string's length.

You should have a constructor/factory for strings that will form/instantiate the string in a valid state, with its value matching its length. That's not the same thing as a setter that mutates the string in-place.

getters, setters, and factories allow the implementation to evolve without breaking client code.

That only matters for interfaces which you expose to clients. The real problem with getters & setters & such is when they gum up the internal workings of a codebase, abstracting over nothing and complicating things unnecessarily.

I agree with that. If you create accessors as a matter of course, then you are mostly adding dead weight. But accessors can add a useful layer of abstraction at the interface layer, as you say.

C# allows you to define getters and setters after the fact without breaking client code.

  foo.bar = x; // could be normal assignment or a setter.

not quite! a property is a pair of methods. if you replace a member with a property, it does remain code compatible as you describe, but breaks the ABI. so if you do this in a published library, clients require a recompile. for this reason, they recommend:

1) different naming convention between members and props

2) dont expose members; use properties from the start for anything public

to assist with two, they introduce the default get/set implementation, like so:

public object Derp { get; set; }

for when you want to expose an interface with the assignment idiom but dont actually have any interesting implementation

Reply on news.ycombinator.com