getter and setters are not necessary, but offer nice syntactical sugar to a language.
Are getters and setters object oriented?
11–20 of 35 posts
Re: Are getters and setters object oriented?
#12There'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... .
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. 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.
Re: Are getters and setters object oriented?
#13No they are not object oriented. Getters and setters are the fundamental elements of Component Oriented systems. Java beans are 'container friendly' and from the very beginning designed for use with tools. Tools developed by 3rd parties.
Having standard getters and setters enabled things such as Spring (which began as a poor man's enterprise container) and have culminated in this http://docs.jboss.org/weld/reference/1.0.1-Final/en-US/pdf/w....
Re: Are getters and setters object oriented?
#14Earlier 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…
Getters and Setters are only semantically correct for Java Beans.
In pure usage of the language, clearly if a class with an immutable public element is appropriate, you may use it.
If you only need a getter for your immutable property (and are not writing classes that are destined by management by a container) then do so. It is perfectly OK.
However, if your Java object is ever going to be treated generically by a tool, container, external system (serialization), etc., then you need to "expose" your internal structure. After all, the user of the object may in fact be tasked with "initializing" the object. (In other words, imagine you are the author of a visual editor for Java programs.)
Before criticizing the good engineers at Sun, remember that annotations were not available back in the early days. Today it is in fact quite possible to design a new specification for Java Beans that delegates ALL code generations to annotation processors and gives you the developer a set of annotations to sprinkle on your otherwise uncluttered Java code.
Re: Are getters and setters object oriented?
#15Using 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) {}
His implementation leaves much to be desired, but there are better ways of doing it.
Re: Are getters and setters object oriented?
#16Languages 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.
Re: Are getters and setters object oriented?
#17And 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.
Re: Are getters and setters object oriented?
#18Languages 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.
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.
Re: Are getters and setters object oriented?
#19Getters 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).
Re: Are getters and setters object oriented?
#20Languages 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.
If you're talking about a narrow view of what new compsci (with a poor programme) person might know (== only java) - yes, these are understood conventions, although even that is not completely true.
Counter-examples: python properties, ruby (=, ? and normal methods), C# properties (and events), probably any message-passing language (via 'name' or ('name', 'newvalue')), lots of other languages mentioned in other comments here...
How is not using setValue, getValue "breaking converntion in a major way" then? Java, PHP, Javascript and some others do it that way. This is their convention - true. But it's far from "an OOP convention" - mainly since OOP doesn't define the syntax in any way - just some properties of the environment.