Are getters and setters object oriented?
arkanis.de
Are getters and setters object oriented?
1–10 of 35 posts
Re: Are getters and setters object oriented?
#2IIRC 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.
Re: Are getters and setters object oriented?
#3The 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...
Re: Are getters and setters object oriented?
#4Getters and setters are a lip-service to the actor model.
Re: Are getters and setters object oriented?
#5There'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... .
Re: Are getters and setters object oriented?
#6[deleted]
Re: Are getters and setters object oriented?
#7There'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... .
[deleted]
Re: Are getters and setters object oriented?
#8And 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.
Re: Are getters and setters object oriented?
#9Using 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'){
// ...
}
} function setSpeed($value) {}Re: Are getters and setters object oriented?
#10There'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 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.