7 ms·

So he discourages Getters/Setters and instead says that declaring the variable as Public is better? I mean, isn't that like not giving a sh-- about encapsulati

by dysoco 14y ago

So he discourages Getters/Setters and instead says that declaring the variable as Public is better? I mean, isn't that like not giving a sh-- about encapsulation principles ?

sgk284 14y ago
We're all consenting adults. Python gets by just fine on this principle.
- zanny 14y ago
  The argument from the Java camp is that if you always use the getters and setters, you leave the access and modification open to extension, say, by adding a callback listener for changes to a variable. I then just say, change it when you need it, and use that fancy "find usages" thing most IDEs and vim have.
  - ufo 14y ago
    Precisely. The real reason Python gets this right is that it the properties feature lets you write `obj.foo` but still call a `getFoo` method behind the scenes.
    - Luyt 14y ago
      C++Builder and Delphi offer this too, with the '__property' declarator.
      - zanny 14y ago
        As someone who writes C++ regularly, I would love to see something like __property introduced in C++15.
npsimons 14y ago
I'm kind of the same opinion as Carmack re: getters/setters. My feeling is, if all you're going to do is allow clients to read and write the variable, why not just expose it? Sure, you can argue encapsulation and even justify it by saying that later down the road you may want to change the implementation, but far too often I've seen C++ classes with a setter and getter for every variable, for no good reason (eg, they're never called, or shouldn't be). I think it behooves programmers to really think about the interfaces their code offers; don't just expose something through setters and getters because it's there, ask yourself, what is this class really offering that you couldn't get with a struct? Pass through setters and getters aren't an abstraction.
- coffeeaddicted 14y ago
  One (maybe stupid?) reason why I really like getter/setters has nothing to do with encapsulation, but that it makes it easier to search for places where a variable is changed. Often you have lots of getFoo and little setFoo functions - so just searching for "Foo" will return lots of results while "setFoo" helps me finding those faster.
  - Too 14y ago
    Most editors with an indexer solves that automatically with "find all references". They can usually even order by "read occurrences" and "write occurrences"
    - coffeeaddicted 14y ago
      VS2010 and C::B both don't seem to allow that ordering. So not a solution for me, but certainly could be other IDE's support that.
  - eru 14y ago
    A only slightly more complicated regex can look for Foo on the left-hand side.
- daemin 14y ago
  Some arguments in favour of getters and setters are; that using a function allows for the addition of caching, addition of thread safety checks, changing to compute the variable rather than store it, addition of logging, mapping it to be generated from another variable, etc.
evincarofautumn 14y ago
For immutable objects, “setFoo()” makes no sense, and “getFoo()” is redundant. For encapsulated objects, “foo” doesn’t need to be exposed at all, not even through getters and setters. A group of fields with no behaviour is not an object—it’s data.

by dysoco 14y ago

So he discourages Getters/Setters and instead says that declaring the variable as Public is better? I mean, isn't that like not giving a sh-- about encapsulation principles ?

sgk284 14y ago

We're all consenting adults. Python gets by just fine on this principle.

zanny 14y ago
The argument from the Java camp is that if you always use the getters and setters, you leave the access and modification open to extension, say, by adding a callback listener for changes to a variable. I then just say, change it when you need it, and use that fancy "find usages" thing most IDEs and vim have.
- ufo 14y ago
  Precisely. The real reason Python gets this right is that it the properties feature lets you write `obj.foo` but still call a `getFoo` method behind the scenes.
  - Luyt 14y ago
    C++Builder and Delphi offer this too, with the '__property' declarator.
    - zanny 14y ago
      As someone who writes C++ regularly, I would love to see something like __property introduced in C++15.

npsimons 14y ago

I'm kind of the same opinion as Carmack re: getters/setters. My feeling is, if all you're going to do is allow clients to read and write the variable, why not just expose it? Sure, you can argue encapsulation and even justify it by saying that later down the road you may want to change the implementation, but far too often I've seen C++ classes with a setter and getter for every variable, for no good reason (eg, they're never called, or shouldn't be). I think it behooves programmers to really think about the interfaces their code offers; don't just expose something through setters and getters because it's there, ask yourself, what is this class really offering that you couldn't get with a struct? Pass through setters and getters aren't an abstraction.

coffeeaddicted 14y ago
One (maybe stupid?) reason why I really like getter/setters has nothing to do with encapsulation, but that it makes it easier to search for places where a variable is changed. Often you have lots of getFoo and little setFoo functions - so just searching for "Foo" will return lots of results while "setFoo" helps me finding those faster.
- Too 14y ago
  Most editors with an indexer solves that automatically with "find all references". They can usually even order by "read occurrences" and "write occurrences"
  - coffeeaddicted 14y ago
    VS2010 and C::B both don't seem to allow that ordering. So not a solution for me, but certainly could be other IDE's support that.
- eru 14y ago
  A only slightly more complicated regex can look for Foo on the left-hand side.
daemin 14y ago
Some arguments in favour of getters and setters are; that using a function allows for the addition of caching, addition of thread safety checks, changing to compute the variable rather than store it, addition of logging, mapping it to be generated from another variable, etc.

evincarofautumn 14y ago

For immutable objects, “setFoo()” makes no sense, and “getFoo()” is redundant. For encapsulated objects, “foo” doesn’t need to be exposed at all, not even through getters and setters. A group of fields with no behaviour is not an object—it’s data.