4 ms·

Controversial might be too strong a word, but there is a counterargument to be made. Suppose you have a member named "x." Someday, you might want to stop stori

by jarrett 15y ago

Controversial might be too strong a word, but there is a counterargument to be made. Suppose you have a member named "x." Someday, you might want to stop storing x, and instead make it a calculated value. At which point you'll need a method. Or, when setting x, you may someday want to increment a counter, or transform the input data, or take some other action. Again, you'll need a method. Yes, it's very easy to add an accessor later. But then you'll most likely have to edit every line of code that accessed the now-defunct member variable. Your IDE may make this easy, but I'd still prefer not to have to do it. That's not to say writing accessors is always the best choice. I'm just saying there can be good reasons to do it. Like all things in software engineering, there's no one-size-fits-all rule about this. Notch is right about the bloat accessors create, so you have to weight the advantages and disadvantages yourself in each case.

lclarkmichalek 15y ago
A lot of languages have constructs that allow changing an attribute into a method call transparently (@property in python and D)
jiggy2011 15y ago
I think this idea is that you can use "properties" rather than public class variables. Then you can convert your public vars into properties at a later date. This means that you will not have to (necessarily) rewrite your code as the language knows that a = myobj.myvar now should call getmyvar() in the containing class and: myob.myvar = a should call setmyvar(a) , I know that C# certainly allows this.
- esrauch 15y ago
  C# allows it but but Java doesn't have this. Hence why it's standard operating procedure to just use setters from the beginning, because it might be nontrivial to update all references.
  - jiggy2011 15y ago
    Play! framework allows you to use getters and setters with public members as you would in C#. Not sure how this is implemented.
    - aaimnr 15y ago
      Spring Roo does the same through the use of aspect programming (code generation, essentially - it generates the boilerplate behind the scenes).
cstuder 15y ago
No. C# and Objective-C (And I assume similar languages too) can have public accessors which are not used like function. No need to add ()'s everywhere.
- InclinedPlane 15y ago
  The way current C# does accessors / properties is just about perfect, I wish more languages would adopt it.
  - masklinn 15y ago
    > The way current C# does accessors / properties is just about perfect As far as I'm concerned it's quite far from it, because C# still allows public fields, properties and fields are incompatible, properties and methods are separate and Microsoft specifies different naming conventions for fields on one hand and properties & methods on the other. Perfection is Smalltalk's way of doing it. And in a syntactic line closer to ALGOL, Ruby is about as good as it gets: no public fields, "properties" are normal methods (setters have a little bit of syntactic sugar, but not much) and auto-generating a bunch of getters, setters or both is a class-level method call.
    - de90 15y ago
      What is wrong with different naming conventions for fields vs. properties, and methods? It makes it immediately obvious what is what at a glance. *Honest question - I first learned programming with C#, and so those conventions seem 'correct' to me.
      - masklinn 15y ago
        > What is wrong with different naming conventions for fields vs. properties, and methods? It makes it immediately obvious what is what at a glance. Which is precisely one of the problems of properties in C#, it makes fields and properties look and feel extremely different from the outside which violates the uniform access principle. As I noted, ideally C# should not have public fields in the first place.
Sufrostico 15y ago
IMHO most software 'service life' it's not long enough to justify the annoyance of the accessors. Most software are outdated after a couple of years. But I still think that accessors are a must if you know that the software will be immortal (like Internet banking applications)
- figglesonrails 15y ago
  That's a pretty brutal stance. :| I can't say I know the average shelf life of a software component in various languages, but I can say that at least things like Java have managed to justify their use of accessors by that metric. Maybe the focus should be on writing less throwaway code than deciding whether to "invest" a few extra minutes or not on accessors.
- Garbage 15y ago
  That is an understatement. I am currently working on a code which was written at 10 years back. And that code is still running on production server. tl;dr; Usually enterprise Java applications does have long "service life".
- dextorious 15y ago
  """Most software are outdated after a couple of years.""" You'd be surprised. Tons of code runs in production, even in the latest of shiny systems, that was written 10 and 20 and 30 years ago -- either in whole or in parts, refactored etc. From 1986's NeXT OS that is now OS X Lion and iOS 5, to Bill Joy's TCP/IP, to Emacs. And tons of enterprise/banking/financial/military systems use ancient code, even 70's COBOL...
- akg 15y ago
  I think most companies have tons of legacy code that is stilly lying around and in production use. When I was at Dreamworks Animation, we were still using tools written back in the 1980s to create animated features; albeit we kept improving on it whenever it didn't fit the bill.
figglesonrails 15y ago
Code bloat, at least _compiled_ code bloat, tends to be less on an issue with trivial accessors in C++ since they are generally inlined, but it does add a lot ()s. For non-trivial accessors, yeah, you can inline a lot of copies of that logic. Vector v1(v2.getX(), v2.getY(), v2.getZ()); vs Vector v1(v2.x, v2.y, v2.z);
tikhonj 15y ago
Gosu supports a property syntax that lets you use = to assign things to get/set method pairs. In fact, when you load existing Java code, it replaces getFoo() and setFoo(foo) methods with a property. This makes the code neater and enforces the abstraction--the user of the property does not need to know whether you've implemented it as a simple variable or a complicated method. A bunch of other language let you do this as well.
- haldean 15y ago
  Python can do this: http://docs.python.org/library/functions.html#property http://docs.python.org/library/functions.html#property
dextorious 15y ago
"""Yes, it's very easy to add an accessor later. But then you'll most likely have to edit every line of code that accessed the now-defunct member variable. Your IDE may make this easy, but I'd still prefer not to have to do it.""" Easy is an understatement. It's 2-3 clicks away in Eclipse.

by jarrett 15y ago

lclarkmichalek 15y ago

A lot of languages have constructs that allow changing an attribute into a method call transparently (@property in python and D)

jiggy2011 15y ago

I think this idea is that you can use "properties" rather than public class variables. Then you can convert your public vars into properties at a later date. This means that you will not have to (necessarily) rewrite your code as the language knows that a = myobj.myvar now should call getmyvar() in the containing class and: myob.myvar = a should call setmyvar(a) , I know that C# certainly allows this.

esrauch 15y ago
C# allows it but but Java doesn't have this. Hence why it's standard operating procedure to just use setters from the beginning, because it might be nontrivial to update all references.
- jiggy2011 15y ago
  Play! framework allows you to use getters and setters with public members as you would in C#. Not sure how this is implemented.
  - aaimnr 15y ago
    Spring Roo does the same through the use of aspect programming (code generation, essentially - it generates the boilerplate behind the scenes).

cstuder 15y ago

No. C# and Objective-C (And I assume similar languages too) can have public accessors which are not used like function. No need to add ()'s everywhere.

InclinedPlane 15y ago
The way current C# does accessors / properties is just about perfect, I wish more languages would adopt it.
- masklinn 15y ago
  > The way current C# does accessors / properties is just about perfect As far as I'm concerned it's quite far from it, because C# still allows public fields, properties and fields are incompatible, properties and methods are separate and Microsoft specifies different naming conventions for fields on one hand and properties & methods on the other. Perfection is Smalltalk's way of doing it. And in a syntactic line closer to ALGOL, Ruby is about as good as it gets: no public fields, "properties" are normal methods (setters have a little bit of syntactic sugar, but not much) and auto-generating a bunch of getters, setters or both is a class-level method call.
  - de90 15y ago
    What is wrong with different naming conventions for fields vs. properties, and methods? It makes it immediately obvious what is what at a glance. *Honest question - I first learned programming with C#, and so those conventions seem 'correct' to me.
    - masklinn 15y ago
      > What is wrong with different naming conventions for fields vs. properties, and methods? It makes it immediately obvious what is what at a glance. Which is precisely one of the problems of properties in C#, it makes fields and properties look and feel extremely different from the outside which violates the uniform access principle. As I noted, ideally C# should not have public fields in the first place.

Sufrostico 15y ago

IMHO most software 'service life' it's not long enough to justify the annoyance of the accessors. Most software are outdated after a couple of years. But I still think that accessors are a must if you know that the software will be immortal (like Internet banking applications)

figglesonrails 15y ago
That's a pretty brutal stance. :| I can't say I know the average shelf life of a software component in various languages, but I can say that at least things like Java have managed to justify their use of accessors by that metric. Maybe the focus should be on writing less throwaway code than deciding whether to "invest" a few extra minutes or not on accessors.
Garbage 15y ago
That is an understatement. I am currently working on a code which was written at 10 years back. And that code is still running on production server. tl;dr; Usually enterprise Java applications does have long "service life".
dextorious 15y ago
"""Most software are outdated after a couple of years.""" You'd be surprised. Tons of code runs in production, even in the latest of shiny systems, that was written 10 and 20 and 30 years ago -- either in whole or in parts, refactored etc. From 1986's NeXT OS that is now OS X Lion and iOS 5, to Bill Joy's TCP/IP, to Emacs. And tons of enterprise/banking/financial/military systems use ancient code, even 70's COBOL...
akg 15y ago
I think most companies have tons of legacy code that is stilly lying around and in production use. When I was at Dreamworks Animation, we were still using tools written back in the 1980s to create animated features; albeit we kept improving on it whenever it didn't fit the bill.

figglesonrails 15y ago

Code bloat, at least _compiled_ code bloat, tends to be less on an issue with trivial accessors in C++ since they are generally inlined, but it does add a lot ()s. For non-trivial accessors, yeah, you can inline a lot of copies of that logic. Vector v1(v2.getX(), v2.getY(), v2.getZ()); vs Vector v1(v2.x, v2.y, v2.z);

tikhonj 15y ago

Gosu supports a property syntax that lets you use = to assign things to get/set method pairs. In fact, when you load existing Java code, it replaces getFoo() and setFoo(foo) methods with a property. This makes the code neater and enforces the abstraction--the user of the property does not need to know whether you've implemented it as a simple variable or a complicated method. A bunch of other language let you do this as well.

haldean 15y ago
Python can do this: http://docs.python.org/library/functions.html#property http://docs.python.org/library/functions.html#property

dextorious 15y ago

"""Yes, it's very easy to add an accessor later. But then you'll most likely have to edit every line of code that accessed the now-defunct member variable. Your IDE may make this easy, but I'd still prefer not to have to do it.""" Easy is an understatement. It's 2-3 clicks away in Eclipse.