4 ms·
I disagree. A fundamental, language-level problem with Java is that clients need to know when they are accessing a member var, e.g. obj.foo, vs. calling a metho
by adevine 12y ago
I disagree. A fundamental, language-level problem with Java is that clients need to know when they are accessing a member var, e.g. obj.foo, vs. calling a method, e.g. obj.foo(). This means that its much safer to always wrap things in a method, because if you ever need to change something (or do things like add logging, delegation, or some other filtering behavior), you can do it behind your method without clients needing to change.
Contrast Java with Ruby or C#. There, the clients don't need to know whether they're accessing a member var or calling a method to get/set a property, NOR SHOULD THEY. The inability to do this in Java fundamentally breaks encapsulation.
- jayd16 12y agoYou haven't addressed his comment at all. Either you're building an immutable object and fields are the proper choice, or you're building an abstract, stateful, concept in which you should be using methods that may or may not map to fields.
- dragonwriter 12y ago> Contrast Java with Ruby or C#. There, the clients don't need to know whether they're accessing a member var or calling a method to get/set a property, NOR SHOULD THEY. Others have noted that in many contexts in C# there is a difference, so clients do need to know. As far as Ruby, clients definitely need to know, its just that since public fields can't happen in Ruby, its always method-based access for the normal cases. Both of these lines are always calling a method on "obj" in Ruby: foo = obj.a # equivalent to foo = obj.a() obj.a = foo # equivalent to obj.a=(foo) While these are using instance var (the closest thing to a "field" in Ruby) access: foo = obj.instance_variable_get :@a obj.instance_variable_set :@a, foo foo = obj.instance_eval { @a } obj.instance_exec { @a = foo } There's no common syntax like C#-style properties that unifies field-based and method-based access, so Ruby is sort of the extreme opposite of attempts to have "properties" that make method-based access look the same as field-based access in the same language, even though its method syntax can make method-based access in Ruby look like field-based access in a completely different language.
- Guvante 12y ago> Others have noted that in many contexts in C# there is a difference, so clients do need to know. Which is why C# added automatic properties. You get the expandability without breaking clients or having to read/write extra code. public int Foo { get; set; }
- Renaud 12y agoWhich becomes even more useful over a field when you can do: public int Foo { get; private set; }
- marvy 12y agoLast time I checked (long ago), properties in C# don't work as ref or out parameters. Since C# actually distinguishes between ref and out parameters, it would be pretty easy to extend the language such that properties work whenever fields work, but sadly no one but me seems to care.
- Guvante 12y agoSee the following example for why that is excluded. public string Foo { get { return ""; } } private void DoBar(ref string input) { input = "123"; } public void Main() { DoBar(ref Foo); } Typically C# points you towards using a different methodology than ref/out parameters. But I do agree it is annoying when you want to use them.
- bcj 12y agoPython has a solution to this. There are decorators that allow you to access methods as if they are properties: class Foo(object): def __init__(self, bar): self._bar = bar @property def bar(self): return self._bar @bar.setter def bar(self, value): self._bar = value
- illumen 12y agoAs does Objective-C, and JavaScript.