Hacker News Reader

Comment by drizze | Hacker News Reader

To provide flexibility in the future. When your data comes from a method you can change its source without changing the caller. This can be very useful and should be leveraged whenever possible.

View on HN

But by definition getters and setters lack lexibility. They expose the internal representation of an object. They stop really being "objects" - high level opaque things you send messages to - and they turn into big porous bags of fields.

To clarify, I would not consider something like this a setter:

    class Monster {
        int health;
        
        void Damage(int d) { 
            this.health -= d;
        }
    }

True, it is a method that just sets a variable. But it makes no mention of that variable. It's defined in terms of its actual purpose (inflicting damage on a monster), not its implementation (modifying an internal field called 'health').

There is definitely a time and place for plain data objects. But if you find yourself actually needing validation and preprocessing in your get/set, then you probably have a 'real' object hiding their. Stop being lazy and give it proper methods.

`Technically` The current representation of `objects` in java is a abomination to the original idea behind object's. Hell even the use of class, members and fields fly in the face of what real objects are.

Do physicists argue about the true nature of gravity because Newton had the "original idea" behind it?

What do you mean by "real objects"? Are you refering to prototype OO?

Yes similar to a prototype language. The original design goals of OOP was you removed your constraints from the machine language and the restrictions that comes with a state based machine. Instead of focusing on mutex’s, member fields, private/public functions inheritance. You took your problem domain and deconstructed it using basic-level categorization into objects.

Those objects themselves would have behaviors and their own internal state. Those objects would communicate with each other via sending messages. It was up to the receiving object how it would or wouldn't reply to such a message. In this model there isn’t a type system as each object send messages to each other. To solve a distinct problem objects would delegate onto each other who would be the best to accomplish the task.

If you needed a object to have new behaviors you would just simply send a message to the object with the new routine/method/function. Just like the real world you could add/remove things from objects without any concern. In this way your objects morphed over time that where a representation of the complexity of the real world.

The problem that happened was a lot of OOP didn’t take place in the domain of the real world instead engineers moulded it to fit into a state based machine. Out went the notion of Objects sending messages to each other because it was too much of a performance hit. Out went the notion of clone objects instead replaced with a central management system such as classes. Next was the constrain of a type system, and inheritance.

The best example of a true OOP language today is javascript/small-talk/prototype languages.

"{}.f is not a function"

oh..

> "abomination to the original idea behind object's"

Whose original idea behind objects? Alan Kay and Dan Ingalls? As recently as September 2017 Gosling publicly stated [1] that Java's object model is entirely based on Simula. Object-orientation didn't start with Smalltalk, and its biggest contribution of the concept of (non-command) messaging between objects (all the way down), has proven none too popular in modern languages (excluding Objective-C), unlike those of Simula which introduced objects, classes, sub-classing and virtual functions.

Java is entirely consistent with these "original ideas".

---

[1] http://bit.ly/2xc1XTA

This is a good argument and I have considerable sympathy with it, but it's actually not an argument against using getters and setters; it's just an argument for making them nonpublic. In a tiny example like this it obviously doesn't matter, but in a large, complex class it can be useful, in my experience, for all assignments to a field to go through a setter. As others here have argued, this provides a convenient hook for changing the behavior of all such assignments -- a hook which is maybe not often needed, but very useful when it is needed.

That said, I don't agree with your argument in all cases. Some classes really are relatively passive carriers of data. My favorite example is AST node classes in a compiler; the logic that controls the transformations applied to these is naturally outside the classes, because most of the interesting postconditions and invariants apply to the entire AST of which each node is only a small part.

Reply on news.ycombinator.com