8

I'm watching a C++ tutorial video. It is talking about variables inside classes and assert that variables should be marked private. It explains that if I want to use them publicly, I should do it indirectly through functions.

Why? What's the difference? It looks like the result is the same, except that instead of having one line of code, I now have like 9 or 10 more LOC to do the same thing.

Can someone explain why converting a private variable in a class to public within the class rather than just making it public right out the simple way is any different and more efficient?

Ampt
  • 4,605
  • 2
  • 23
  • 45
Kendra Kaye Coffey
  • 81
  • 1
  • 1
  • 2
  • If my bank account balance was a public variable I'd either be rejoicing or more probably weeping. Unfortunately the only way to change my balance is through a mundane function such as withdrawal or deposit. –  Jul 12 '14 at 23:55
  • By the way, [this](http://pragprog.com/articles/tell-dont-ask) might be of interest to you. Sure, getters and setters are better than public variables, but ideally there are even better solutions... – awksp Jul 13 '14 at 00:20
  • 1
    @ooo Bad analogy. Public variables aren't accessible to everything; they are still only accessible to running code. Your bank balance might well be a public variable in the bank's system and it would not have direct security implications (although it may increase the chance of there being other bugs). – user253751 Jul 13 '14 at 03:19
  • 1
    It's important to say that while getters and setters are better than a public variable, the popular notion that "private variables + getters and setters = encapsulation" is *very wrong*. In practice, getters and setters are just a little better than public members, and using them doesn't guarantee encapsulation. The important thing is to really think what is part of the public functionality of the class in the system, and needs to be exposed, and what needs to be hidden (i.e. private and no accessors or mutators). And not exposing everything blindly through getters and setters. – Aviv Cohn Jul 13 '14 at 20:23

2 Answers2

11

There are a few reasons to use setters and accessors as opposed to simply making variables public.

1. Separation of concerns - The consumers of a class shouldn't know, or even care, whether what they're accessing is a primitive variable, or something more complex. For example, let's say I had a Car class, and that car has a horsepower. You can get the horsepower by calling the getHorsepower() method, and you can set it with setHorsepower(int power).

Now, a consumer of this class really doesn't care what goes on under the hood, just that there is a horsepower method. But what if, on the backend, setting the horsepower meant changing the engine? When you call setHorsepower, it will find an engine that can provide that, and call the private method setEngine(Engine newEngine) to make sure that the car's behavior is consistent!

2. Code maintainability - When you set up the class, it may make sense to only have a public variable, but you quickly find that you need to do error checking on the variable, or you need to have a change in that variable update another object. If you provided the public variable, you would need to change all the classes that use that and then have them either A) Implement all the functionality you need them to like error checking, or B) Change them to use an accessor. By having them use the accessor, you can modify all of that in one place instead of having to keep track of all the places that use that variable.

Ampt
  • 4,605
  • 2
  • 23
  • 45
  • Note: In other languages with good IDE support, like Java, point 2 isn't as applicable. In Eclipse for example you can just right click a field and select `Refactor -> Encapsulate Field` – user253751 Jul 13 '14 at 03:21
  • 4
    @immibis this would be sufficient if your class was only being used in your own local project, but what if you were building an API that people from all parts of your software company need to use? You would annoy quite a few people if you asked them all to update their own code to use getters and setters where a public variable previously existed. – SimonT Jul 13 '14 at 03:37
  • @SimonT right; forgot to say that in my previous comment – user253751 Jul 13 '14 at 04:46
6

Getters and setters are poor design as well. They are better than public variables because they allow the class to enforce invariants. To borrow Ampt's example setHorsepower is better than a public horsepower variable because the car class can ensure that horsepower is never negative with the setter, but can't guaranty anything about a public variable. While that is better than nothing, a better design would have car instances in charge of their own horsepower. Any code that is mucking about with the car's internal state should be apart of the car class. It shouldn't have wondered off and gotten lost somewhere else.

stonemetal
  • 3,371
  • 16
  • 17
  • I agree with the principle but, for instance, a `Point` class is at some point going to have to provide coordinates... how else than with accessors? – Casey Sep 22 '15 at 20:33
  • @Casey You're right eventually you will need getters and setters somewhere, and when that time comes they will be the right tool for the job. In general though getters and setters show a lack of encapsulation because the class's internal state is leaking out. – stonemetal Sep 24 '15 at 16:07