Are getters and setters a bad idea? (discussion)

[Gonzalo Chumillas]

What do you think about getters and setters? I'm not talking about traditional getters/setters methods (getXxx() and setXxx()). I'm talking about the language construction. For example:

class MyClass {
  String _str;
  String get str => _str;
  void set str(String value) {
    _str = value;
  }
}

I think they are "evil". The reason is why they are hiding valuable information to the user. Specifically: information related to performance. That is, let's consider the following innocuous code:

myVar.driveCpu = 100;

It actually calls secretly the following method:

myVar._setMyDriveHardAndMyCpuHot(100);

Obviously, you don't want to call the previous method frequently. It may compromise the system.

What do you think about this transcendental question? I'm not sure if using accessor methods are good idea.

Thanks and sorry my awful English.

[Lex Berezhny]

If the setter is doing a lot more things than just setting a variable then it's not a setter.​

Don't call `setMyDriveHardAndMyCpuHot()` inside of your setter and you'll be fine.

[Bob Nystrom]

On Thu, Jun 23, 2016 at 9:08 AM, Gonzalo Chumillas <gonzalo....@gmail.com> wrote:

What do you think about getters and setters? I'm not talking about traditional getters/setters methods (getXxx() and setXxx()). I'm talking about the language construction. For example:

class MyClass {
  String _str;
  String get str => _str;
  void set str(String value) {
    _str = value;
  }
}

I think they are "evil". The reason is why they are hiding valuable information to the user. Specifically: information related to performance. That is, let's consider the following innocuous code:

myVar.driveCpu = 100;

It actually calls the following method:

myVar.setMyDriveHardAndMyCpuHot(100);

Obviously, you don't want to call the previous method frequently. It may compromise the system.

What do you think about this transcendental question? I'm not sure if using accessor methods are good idea.

When you're using some API, you want your code to look clean and focused on the domain of your program. If the object you're working with conceptually has some properties you can modify or access, then getters and setters are the natural syntax for that:

var bostonCream = new Doughnut();

bostonCream.filling = Filling.cremePatissiere;

bostonCream.topping = Topping.chocolate;

print(bostonCream.deliciousness); // 1000000.

Adding "get", "set" and "()" to every call is just pointless noise. It makes you notice the programming language's machinery instead of thinking about your program. In the above code, you want to think about doughnuts, not Dart syntax. The syntax is just a means to an end.

In most cases, whether or not a "property" is a field or the result of some computation is an implementation detail. It may be an implementation detail with performance that is somewhat slower than a direct field access, but that's OK. Dart is a high level language. Keep in mind that even adding two numbers may involve heap allocation!

The absence of "()" is not a strong signal in Dart that "this thing is very fast". That is a convention in other languages, and could have been one in Dart, but we didn't pick that convention, and users shouldn't expect it.

However, if the user of your API is more focused on the work the operation performs than they are the value passed in or the result returned, then in that case, a method is likely a better fit than a getter or setter. Give the method an imperative name that describes the work being done. If you find yourself naming it "get___" or "set___", then just use a getter or setter.

If you name it "download___" or "send___" or "calculate___", or "update___", then you're on the right path with a method.

Performance is one reason why they may want to focus on the work being performed, but it's not the only one. A very fast operation that has a visible side-effect might also be better as a method than a getter or setter.

See also: https://www.dartlang.org/effective-dart/design/#members

Cheers!

– bob

[Gonzalo Chumillas]

Thanks! Your explanation was very instructive.