0

Say I have a class called Person that has two attributes: age and dateOfBirth.

Now since I want the age attribute to be changed according to the dateOfBirth attribute, I will create a setDateOfBirth() method that will set the dateOfBirth attribute and also calculate and set the age attribute.

My question is why should I make these attributes private if I am (the programmer) the only one accessing the object directly and I know not to change them without accessing the methods. The most obvious reason I can think of is that I could change them by accident, and so making them private will prohibit me from doing that, are there any other reasons for making the attributes private?

  • 2
    If it is only your code and you are the only person that will ever see it or use it then do what makes you happy. If not, there's a lot of discussion about this subject here: http://stackoverflow.com/questions/5168981/what-good-are-public-variables-then/ – Retired Ninja Feb 01 '15 at 10:30
  • 1
    There's a saying that every software development team consists of at least two persons, those two persons being you and you in six months. This contradicts your claim that you are the only one who will ever touch that code. That said, if it's for a one-off task, I tend much stronger towards laziness (called "efficiency") than perhaps when working on a fundamental library that will be used widely. – Ulrich Eckhardt Feb 01 '15 at 10:55
  • @RetiredNinja, I had to give away the code that "only I am supposed to see" a couple of times now. It was a pretty embarrassing experience :) So it's best to to things properly all the time. Just in case :) – FreeNickname Feb 01 '15 at 11:07
  • @FreeNickname Yeah, me too. Some "Hmm, I wonder if this would work?" experiment code worked so well that we shipped it in a dozen games. It was dreadful but it worked well enough and nobody ever felt like cleaning it up, they just kept adding more ugly to it. – Retired Ninja Feb 01 '15 at 11:14
  • Becasue the only way you can *be* sure you're the only one accessing the objects attribute is if they *are* private. – user207421 Feb 01 '15 at 11:16

1 Answers1

2

It would be better to have one of those two stored as a data member, and have the other calculated from that by a member or even free function:

struct Person { int dateOfBirth; };
// Simplistic and only correct for about half a year
// No need for thisYear to be static or even hardcoded, just for demonstration purposes!
int ageFromDateOfBirth(int dateOfBirth) { static const int thisYear = 2015; return thisYear-dateOfBirth+1; }

As you note, this is a case where you cannot keep both as public data members. Nonetheless, as the calculation is quite basic, and there's a one-to-one correspondence between them, keeping only one is enough. Note you might just as well write a age member function that takes no arguments. Or a free age function that takes a const Person&, for that matter. Thats entirely up to you.

And yes, I am in the "school" that says public data members are ok. Trivial getters and setters are evil, and should be avoided at all costs (thanks to @Retired Ninja for pointing out the question in which @Tony links this article).

rubenvb
  • 74,642
  • 33
  • 187
  • 332
  • While I don't necessarily like trivial get/set functions they do have the benefit of potentially allowing you to make changes in a single place when needs change or bugs arise. It's much easier to put a breakpoint in a setter or log an error when you find that something is setting a variable to a weird value instead of trying to figure it out from the 400+ places a public variable is manipulated directly.. – Retired Ninja Feb 01 '15 at 10:42
  • @Matt Of course it shouldn't even be hardcoded at all, but for this simple example there is nothing wrong with a function local static, [its initialization is even thread-safe](http://stackoverflow.com/questions/8102125/is-local-static-variable-initialization-thread-safe-in-c11), after all. I'll add some clarification (and `const`). Actually, `constexpr` would make the most sense for hardcoded variables. But it's only a quick example anyway. – rubenvb Feb 01 '15 at 10:48