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.
Are getters and setters object oriented?
21–30 of 35 posts
Re: Are getters and setters object oriented?
#22I 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.
Re: Are getters and setters object oriented?
#23I 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…
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.
Re: Are getters and setters object oriented?
#24And 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.
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.
There is direct ivar access, but no sane person uses it outside of the class itself :P
Re: Are getters and setters object oriented?
#25Getters 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).
What you ought to be doing is making trade offs that make sense for your situation without following any particular religion.
Not OO (Object Oriented) is high praise in situations where the OO solution would be worse.
All heuristics should be ignored if it suits the situation to ignore them. OO is one of many a heuristics for software design.
Sometimes a deposit abstraction is simply a waste of conceptual budget and is best avoided.
Re: Are getters and setters object oriented?
#26I 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…
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 tha…
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.
Re: Are getters and setters object oriented?
#27Earlier quoted context omitted.
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 sh…
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. Y…
"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.
Re: Are getters and setters object oriented?
#28Getters 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).
What you ought to be doing is making trade offs that make sense for your situation without following any particular religion. Not OO (Object Oriented) is high praise in situations where the OO solution would be worse. All heuristics should be ignored if it suits the situation to ignore them. OO is one of many a heuristics for software design. Sometimes a deposit abstraction is simply a waste of conceptual budget and…
[deleted]
Re: Are getters and setters object oriented?
#29One 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)
Re: Are getters and setters object oriented?
#30It'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?