The use of getters and setters for different programming languages [closed]

Answer 1

It's OK to have all public variables in any language. Yes, I know it's the opposite of what you learned.

OO theory says that there should be a public API that is stable, and private variables, where you can do whatever you want, and an implementation you can change to your hearts delight without changing the API.

And this is correct. But what is not correct is the idea that the private API must be made inaccessible from other classes. This is simply a mistake in the OO theory. It is an idea that sounds reasonable on paper, but in practice has little to go for it, but causes plenty of problems.

For example, many years ago I needed to subclass a widget in Delphi to make it behave slightly differently. Not a lot you see, just a bit. But the code I needed to override called a method that was private, so I couldn't override it. Instead I needed to override both methods. And of course, that other method did things that was really internal, so I ended up basically not subclassing the widget, but duplicating it, just because I did one small change.

OO theory claims this is how it should be, because horror of horror, maybe otherwise my sublclass might stop work with the next version of Delphi, if the superclass changes something internal! Well, so what? In that case I would just fix it.

It's my problem if I use parts of your internal data. You don't need to care. What you need to do is somehow flag that "This bit is internal and might change, use on your own risk". But when you as a developer of a library actively prevents me from using internal bits, you are only causing me problems.

I've now developed almost exclusively with Python for soon to be ten years, and the openness of Python has never caused me problems, and it fact has saved my ass several times (as I can fix framework bugs by simply patching in fixed code at runtime). Delphis standard OO model with different levels of protection caused me problems several times during the two years I worked with it.

The OO Theory is in fact wrong. There is nothing useful in having private members. Everything should be public. And that goes for any language, in my experience.

Answer 2

It should actually be all the same. I always refer from a real life situation, before putting something to public or not. Can everyone have access to the engine of my car?. Most of the time, the answer is no, because it is mine. People may look at it, but they cannot change it, because they want to.

So getters and setters are always important in every language. The only thing is, that it is different in different languages on how to set the access rights. So as you state, if Python really wants to set everything to public, that seems wrong to me. But setting access rights in MATLAB to some kind of extend, seems very right to me.

As for the difference in properties and getters. Most of the time, if both are available in a language, there are some rules for that. For example, in C#, it is encouraged to use properties, when the property behaves like a normal variable and it is ensured that the function is only O(1). If the property has more to do, like extra logic, a function should be created instead [Rules of properties in C#].

Concluding: Everything should be as private as possible. Create the access points yourself. Properties are getters and setters in a nice layout, because it looks like a variable and does some extra checks if needed. But not too much.

Answer 3

Depends on how abstracted you need. For example, I recently needed a getter and setter in C++ when abstracting a Text object. The Direct3D text object just held a string Text member variable. The Direct2D Text object however had to be recreated and recached and that kind of thing. If I had opted for public variables when designing the original abstraction, I would have had to redesign the interface and change all the dependent code. While I agree that getters and setters over certain kinds of class are pointless, there are some cases in which they are necessary.

Of course, languages with properties don't need this kind of thing. But conceptually, they're the same. Defining a property over a variable is just a getter and setter with syntactic sugar, and while I support syntactic sugar, it doesn't change the encapsulation. I wouldn't change my encapsulation design on a language by language basis. Of course, the community opinion on whether or not encapsulation is a good thing is another matter- that's likely the difference that you're seeing. In C++ encapsulation is rated very highly, whereas the Python community cares for it less.

Answer 4

Python, being a dynamic scripting language, is less about compile-time constraints, and more about flexibility.

Getters and setters ("property" is just getter + setter) allow for better encapsulation (checking validity, only getter, not setter; implementation details does not matter - e.g. time has hours, minutes, seconds, but how are data actually stored? who cares?), and future extensibility (e.g. code of setter might change, consumers don't care).

In modern efficient languages like C++, there is inlining, so there is no performance cost for simple getters/setters.

Point is, use public fields for structural and simple (small-scale) programming, use getters and setters for large-scale OOP projects.