Are getters and setters object oriented? - Arkanis

Comment by Stephan

2011-02-02T17:05:41+00:00

I programmed in VisualBasic 6.0 some years ago and I vaguely remember some kind of "Property Get" or "Property Set" stuff. Nice to see it in the new .Net syntax.

Hm, but is "property overloading" something different from wrapping setters and getters into an API to hide their existence, very similar to the way .NET properties work?

No, it's exactly that. The whole point is that you can add "property specific" code later on without changing the code that uses the property. Java doesn't allow that and therefore the get/set Method convention was established. Unfortunately this convention got the reputation of being "good object orientation practice" and therefore people used it even in languages that do not have that problem. I saw that when Extbase was demonstrated on the WebDay 2010 1. Because of that I decided to write a bit about it hoping that a few people think about that before the use getter and setter methods in PHP.

In retrospective I should have chosen another title for the post. "Are getters and setters object oriented?" is aimed at the people that actually believe that getter and setter methods are an integral part of object orientation. That exposure of state actually breaks encapsulation and therefore a good deal of object orientation is an even higher-level problem that would be very difficult to understand for those people.

Comment by Andreas Stiegler

2011-01-31T20:02:43+00:00

Hm, but is "property overloading" something different from wrapping setters and getters into an API to hide their existence, very similar to the way .NET properties work? This would allow having an internal _Speed as vector2, reading or writing it as float via the get and set part of a property, but accessing it just like a public field, just like in your D example above. The syntax is even quite similar. Be warned, VB incoming!

Public Class Car
    Private _Speed As Vector2
    Public Property Speed As Double
        Get
            Return Math.Sqrt(_Speed.X * _Speed.X + _Speed.Y * _Speed.Y)
        End Get
        Set(ByVal value As Double)
            If value < Epsilon Then value = Epsilon
            Dim speedThroughLength = value / Speed
            _Speed.X *= speedThroughLength
            _Speed.Y *= speedThroughLength
        End Set
    End Property
End Class

and somewhere else

Dim mercedes As New Car
mercedes.Speed = 7
Console.WriteLine(mercedes.Speed)

I might be spoiled a bit from game development, but i threw the holy grail of OO out of the window a while ago and never found it again.
Performance, performance, performance

Comment by Stephan

2011-01-01T17:07:40+00:00

Well said. 🙂

Comment by Nils Jonsson

2011-01-01T07:25:33+00:00

Real question is whether methods that expose state are OO. Tell, don't ask, and you'll be working with objects instead of glorified structs.

Comment by Stephan

2010-12-26T17:17:20+00:00

I'm not sure I understand your point. The syntax for properties in C# looks somewhat strange to me but I have never really programmed in .Net so I can't judge if it's consistent with the language. I don't understand where .Net adds awareness for properties because the user of an object can use it the same way as normal fields. Otherwise it would break encapsulation (or that what's left of it with getters and setters).

I can see advantages in documentation but here Python, Ruby and D offer the same way to extract that information. In PHP it's a bit more complex since there are no established coding conventions for property overloading I know of.

Regarding the awareness that exceptions are thrown I'm a bit surprised. I don't know what programmers are supposed to think while programming .Net but it sounds strange to me that someone would actually expect a specific part of the code not being able to throw an exception. Maybe I'm spoiled by Ruby in this regard, don't know. The only thing I can think of in this direction is that try/catch blocks are a bit clumsy and therefore only used when absolutely necessary. The scope guard statement 1 of the D programming language would surely help there. But exception handling is a whole different topic.

I'm pretty sure I misunderstood your point, so if you have a view minutes I would appreciate a deeper explanation.

Comment by Valentin

2010-12-23T12:06:56+00:00

I partially agree. Because a good thing about getter and setter-Methods is that they are in fact methods. This raises some awareness, since programmers know that methods might throw IllegalArgumentExceptions or something like that. A property however has a passive role in general which may lead to a more careless use of the property.

I personally find a nice way to handle getters- and setters is the .NET-Approach. In .NET they distinguisch between fields and properties. While Properties can be used like simple fields it is perfectly clear that they might contain validation code and throw exceptions. This raises awareness on the programmers side but still makes them usable in a straightforward way.

Comment by Stephan

2010-12-21T11:17:17+00:00

Ruby solved this problem in a very consistent way: there simply are no externally accessible properties (in Ruby instance variables). What happens is that the attr_accessor() function defines getters and setters for all passed instance variable names. So in Ruby the indirection is always present but usually hidden by the shortcuts attr_reader(), attr_writer() and attr_accessor(). 🙂

The reason why I didn't mention Ruby was that I never saw Ruby code that used getters and setters (methods named get_xyz or something like that). Everyone uses the attr_* functions. It seems Ruby programmers simply do not have this problem thanks to the strong coding conventions of Ruby.

Comment by S2

2010-12-20T20:47:50+00:00

>> #Don't forget ruby! 🙂
?> #
?> class Car
>>   attr_accessor :speed
>> end;
?> c = Car.new
=> #<Car:0xb77bd538>
>> c.speed = 10
=> 10
>> c.speed
=> 10
>> class Car
>>   def speed=(s)
>>     @speed=s
>>   end
>> 
?>   def speed
>>     @speed
>>   end
>> end
=> nil
>> c = Car.new
=> #<Car:0xb779d10c>
>> c.speed = 10
=> 10
>> c.speed
=> 10
>>

Comment by Me

2010-12-20T03:32:49+00:00

This is useful. Have never thought about this.
So python, PHP and D dont need setters and getters.

Comment by Stephan

2010-12-20T03:29:02+00:00

I fixed the typo Erick, thanks. 🙂

The JavaScript proxies looks very promising. It's interesting they didn't made everything interceptable (e.g. identity operator, instanceof, typeof, …). Should make debugging easier. I used a similar construct in Ruby to inject internationalized objects into Rails 1.x (SimpleLocalization plugin) and debugging these proxies was… interesting.

The more explicit approach of ActionScript 3.0 looks good. Actually in D2 it is advised to add the @property attribute to methods that are meant to be called as properties. It's not yet required though.

The Python approach looks very interesting, too. Actually defining the property with two handlers… almost a bit JavaScript like. Good to know, wouldn't have expected that. 🙂