

Are getters and setters object oriented? - rb2k_
http://arkanis.de/weblog/2010-12-19-are-getters-and-setters-object-oriented

======
raganwald
Getters and setters aren't object-oriented, and for that matter they aren't
good examples of encapsulation, either. It varies from case to case, but
cherry-picking, if I have an account, I don't care whether I write
account.balance = $100 or account.setBalance($100). What I _ought_ to be doing
is defining semantically rich methods such as account.deposit($100).

~~~
arkanis
I agree that getters and setters aren't object oriented. It was the whole
point of my blog post to make people think about that. It wasn't written for
people who already understand that, though… otherwise it would be quite a bit
shorter. ;)

The sad thing is that way to much people think "getters and setters" when they
hear "object orientation". Maybe even "Eclipse will do that for me". Needless
to say that encapsulation isn't understood then, too. But encapsulation is
bigger topic of it's own and would have been to much for that post.

While talking about that with other people I got the impression that just
explaining the way it was meant to be does not work well. Especially if a
professor and many books tell otherwise. Therefore I try to make people think
for their own about the problem. Showing the problem, how it is solved and how
it can be solved in other situations. I don't know if I succeeded in that.

~~~
raganwald
Well, I upvoted the article and I think I tweeted it as well. So it passed the
"It made me think" test, thank you!

------
goalieca
The university I went to for my undergrad very much drilled it into us that
Getters and Setters are the thing to do. I got out into the working world
after that and it seems everyone else was taught the same thing. When I
actually came to change things it never seemed to help and I always had to
rewrite mountains of cruddy things. It came to the point that I would automate
so much of the code generation using python. If I can automate it with a tiny
fraction of the code then there is certainly something wrong with the design
and premise.

These and other similar things drove me to hate OOP and software engineering.
It seems like people always missed the proper abstraction. Then I discovered
Haskell and wandered more into the theoretical aspects of computer language
theory. I now have an appreciation for OOP but not the way I was taught...

------
epochwolf
And ruby has a nice solution for this. It allows methods ending in = to act as
setters clean overrides and provides methods (attr_accessor and friends) to
generate vanilla getters and setters for you. You _can_ access instance
variables via instance_variable_get but that's not recommended.

~~~
Xuzz
Objective-C is similar -- you have "setters" and "getters", but since there is
no direct ivar access and you have the convenient @property syntax, you end up
with a reasonably similar end result.

~~~
ryanpetrich
There is direct ivar access, but no sane person uses it outside of the class
itself :P

------
arethuza
I seem to recall the whole getter/setter thing becoming popular with JavaBeans
(note not EJBs). Java didn't have a nice way of identify something as a
"property" that could be exposed graphically through an IDE interface so
adopted a syntactic convention. This soon became adopted as "best practice"
even though I suspect 99.9% of getters and setters do nothing but expose an
underlying field - as with most programming "best practices" very few people
can actually tell you what the benefits are supposed to be.

~~~
prodigal_erik
The sad thing is all JavaBeans needed was named arguments to the constructor
rather than relying on setter names. It's a lot more complicated for every
class to let instances be created in a mostly-uninitialized state, relying on
a bunch of setter calls in an unspecified order to make the instance actually
usable. For one thing, there's no language-supported way to make a setter
mandatory, you can't do any better than blowing up _at runtime_ if it wasn't
called.

~~~
artsrc
Spring prefers setters and getters (the constructor support is not as good),
and this makes it harder to communicate what is optional configuration with
defaults and what is essential.

------
olalonde
Using property overloading to implement getters/setters in PHP is terrible
practice. It's slow, makes the code hard to manage and introduces unexpected
behavior.

    
    
          function __set($property, $value){
                if ($property == 'speed'){
                   // ...
                }
          }

Just write the damn setter or no setter at all but please don't use property
overloading for this!

    
    
         function setSpeed($value) {}

~~~
true_religion
His implementation leaves much to be desired, but there are better ways of
doing it.

<http://pastebin.com/JiEXp6Za>

~~~
arkanis
The example is the most simple way I could think of. It should only show that
is is possible not what is the perfect solution (if there is any).

Of course you could throw in some runtime reflection and variable function
calls to make it more maintainable. However for me it needs to pay of… I don't
want to maintain such a system for just a hand full of properties. I like to
keep complexity "flat" and so I often stick to the direct language features.
But on large projects the code you linked could really come in handy. Thanks.
:)

------
gintas
There's a more interesting point to be made about getters and setters than the
article offers. In my opinion, getters and setters are a little stinky because
by nature they expose internal attributes of the class, even if they wrap them
up in method calls. See [http://stackoverflow.com/questions/565095/java-are-
getters-a...](http://stackoverflow.com/questions/565095/java-are-getters-and-
setters-evil) .

~~~
jerf
The entire point of a getter/setter is to hide the internal attributes of the
class behind a layer you can later change, and therefore they aren't
"actually" exposing the internals, they just happen to be implemented that way
at the moment but may later change.

However, the problem is that they are a code smell, specifically of a designer
that doesn't really "get" OO. If you really have it all set up correctly, it
should be rare for you to have one object do nothing more than query another
object's internals, the first object should be telling the second object to
_do something_ , and shouldn't need the internals, wrapped by functions or
otherwise. For all the teaching and the way it is the "official paradigm" of
software engineering, very few people actually understand it well enough to
use it properly. The end result is that the getter/setter user rarely finds
they actually have any use, because anyone making pervasive use of them has so
many _other_ flaws in their design that they are going to have to rewrite
everything anyhow.

~~~
pbourke
You almost always need to have a client object observe the state of an
instance - clients need to marshall it for the network or log some information
about it, etc. So getters make sense.

It's a problem when people assume that getters and setters must always occur
in pairs. They shouldn't! Getters can expose whatever is needed to communicate
the object's external identity and state. Setters are mostly a code smell. You
should pass whatever you need to a constructor and use behavioural methods to
mutate the internal state after construction. For instance, a Car class can
have a getSpeed(), but shouldn't (in a clean design) have a setSpeed(). It
should have stepOnTheGas() or increaseSpeed().

Getters and setters make classes into little more than verbose structs.

Obviously everything I've said is aimed mainly at Java-ish languages, which
was the focus of the OP's comment.

~~~
jerf
"You almost always need to have a client object observe the state of an
instance - clients need to marshall it for the network or log some information
about it, etc. So getters make sense."

It's always a challenge to figure out when to cut off my discussion since I
could go on for quite a while :) But definitely there's some cases for them.

Another example where they do make some sense is when it really _is_ a verbose
struct. A "Point", 2D, 3D, or otherwise, is generally a struct. You may have
some basic methods on it, but you're going to be examining the internals of it
an awful lot for anything nontrivial. (And I've fiddled with some serious OO
design patterns, like layering transforms on the Point objects themselves, and
the problem is that performance has always been terrible then.) You know you
have one of these cases on your hands when you realize that you don't even
need the getter/setter, you might just as well expose the internals, because
the internals _are_ what the object is.

(Like most, I was educated into OO dogma, and one of the earlier clues that
something was wrong with it were these sorts of things that simply _weren't
objects_ and shouldn't be. A Point is just a Point, and trying to abstract the
point usually isn't worth it. You very well may want to layer abstractions on
top of that that provide further guarantees, and I usually stick some methods
on the Points for syntactic convenience, but the Point is not itself a very
good object.)

Also, if you're marshalling, you do need _some_ sort of symmetry for getting
and setting, though I prefer the getSomethingMarshable() and
setWithSomethingMarshalled() (or constructWith...() ) blob approach you often
see in the dynamic languages.

------
dlib
IIRC the property overloading in PHP is slow, especially compared to
hardcoding the getters and setters, so you're better off hardcoding them.
Property overloading in itself is a neat feature for syntactic sugar, for
example an object with (semi-)dynamic properties like in an ORM. Other
properties of classes, those nog generated on the fly, are better off with the
getters and setters written out.

------
ssamuli
It's somehow unbelievable how long this getter/setter convention has been used
(at least?) in java - People mindlessly generating them with their IDE - and
nobody cared to question it and/or think of a better way before.

Not sure if "they are OO" (and what's the point?), but I think getters and
setters usually are not needed and only add a lot of useless boilerplate code.
Maybe in your boss's eyes it might look like you've been writing a lot of
code. :)

But of course sometimes they are useful, and those times I think python's
approach would be a better way. Maybe some other languages have even better
ways to accomplish this?

------
Jach
Getters and Setters violate encapsulation just as much as accessing properties
directly, so I don't bother with them unless I'm forced to. In languages like
C++ they can make sense due to a need of allocating and freeing memory of
things within the object, but it's still not OOP. What you have when you're
using getters and setters is a fancy struct with methods, not an OO class.
(There is a significant difference.) Stop pretending you're not using a struct
and just access things directly or start following a 'draw thyself' model.
Both approaches work.

~~~
arkanis
I very much agree, but saying it in such a way won't help others to understand
that. That is persons that haven't understood the significant difference right
now.

------
mahmud
Getters and setters are a lip-service to the actor model.

------
wlievens
One of the issues the whole setter/getter convention creates is that, for
instance, I'm now reluctant to write a setter method that _does more than just
set the field value_ [1], because some other programmer or some tool might
expect that it is no more than a property mutator.

[1] Example: child.setParent(parent) would perform parent.children.add(this)

------
maxklein
Languages are based on widely understood conventions. If it looks like I'm
writing to or from a variable, then let that be what happens, because that's
how 98% of programmers will understand it to be.

Don't just change it, because the change seems "cleaner". You are breaking
convention in a major way, and this will surely lead to worse code in the
future.

~~~
raganwald
Yes, but if a language provides a mechanism whereby what look _in other
languages_ like property accessors can actually be implemented as method
calls, then in that language, 98% of programmers ought to--like true scotsmen
--expect that it might be a variable and then again it might be a method call.

Case in point: In Ruby, foo.bar and foo.bar= are never property accessors,
it's just that sometimes there exists code such that foo.bar returns @bar and
foo.bar= sets @bar.

------
cwbrandsma
getter and setters are not necessary, but offer nice syntactical sugar to a
language.

