Why use meaningless setters/getters?

Hi all.
All sorts of interesting books on the pros recommend to do the access class members via methods. In principle, this has some meaning, because in the setter you can check what we were given, and whether the error value. Again, we can use the same method to notify others to update, for example the GUI... Well, the getter need just a few to be able to read without changing (bypassing the setter or at all).

However, sometimes I notice here is:
class BlaBlaBla {
public:
 URLID the id() const { return id_; }
 void set_id(URLID id) { id_ = id; }
...


And I can not understand why this is? For my taste it is something akin to Overengineering and does not carry any meaning.

Or am I mistaken?
June 10th 19 at 14:56
3 answers
June 10th 19 at 14:58
When you need to add in validation setter and getter caching, you don't have to change the calls in the client code. Moreover, accessors can be done virtually.

The IDE generates this code perfectly, and he easily turns in the macro. Many compilers have language extensions that allows you to implement properties in C++.
June 10th 19 at 15:00
The value can be, for example, private. And we want to be sure that there is always exactly what we expect getters and setters, and a lot of sugar, just to prevent mistakes/carelessness of the programmer
Can. And most likely it is.
But the getter and setter public. So access is still there at all.
And it seems that you can just throw methods, and a member id_ place in public.
The result would be the same.

In General, do not understand. - Kim commented on June 10th 19 at 15:03
the essence of the setter, the value itself is usually protected or private setter cecem that came to believe on the basis of something else, remember, doing something else, the getter give. And to not constantly repeat the logic of the method is displayed in the method. Basically it makes life easier, but it is written as it seems the "extra" code. Now do a lot of spell where a bunch of seemingly unnecessary code, in practice further helps when all this is posted in a bunch of code that even if he wrote, begins difficult to understand. - Wava_Berni commented on June 10th 19 at 15:06
today you just need to set the new value of the variable, and tomorrow will need to add a check before setting a variable... And these plants a lot of throughout the program, will be everywhere checking to sculpt? Much easier to do the interface, and then in other parts of the code stupid to use it. - aurelio_Kirlin commented on June 10th 19 at 15:09
Well, that is the only reason - a sort of Foundation for the future. Yes?
(Actually, I have even stale FAR is find/replace. Hmhm). - Kim commented on June 10th 19 at 15:12
June 10th 19 at 15:02
The reasons can be a lot.
1. What if today's field is located in a private variable, and tomorrow will accrue from the HTTP response ?
2. What if today it is in the form of a stored value, and tomorrow will be computed?
3. What if today it is in this class, and tomorrow decided to move to another, and not to do too much refactoring yet decided to leave as is?
4. What if today is a property of this class, and tomorrow's parents?

The reasons are many! Getters and setters save you from headaches.

Find more questions by tags C++