Doubt regarding in the accessing of a member variable

One of its usages is to control access to that member variable and have an event whenever anyone reads its value (and you may change its real value and return another thing or may you update some internal state of your object)

This is not required (while considered to be a "bad style"), until:

1. You need to make this member read-only
2. You are implementing specific interface that requires presence of such property
3. You just hiding exact method that calculates result that is not stored directly in the field, but obtained from other properties or members, and presents value as property to be better distinguished from "real" methods.
4. You wan't to make calculation above only when requested. Ofc. there is a lot reasons to use method instead...
5. You want to provide additional logic to the class when someone modifies the value of the member - like throwing an event or validating data for being correct, or releasing some dependant resource... or whatever else...
6. Other ideas? I assume one can find a few :)

Generally this is sorta OK to use only public field (but with name like would property have, so "Id" not "_id") when this is just a storage for some value. Changing it into Property when some additional logic is required, will have no impact on a code that uses it (ofcourse until you limit access to the member...).

Regards
Seb

If you want to hide the internal structure of the class object you need to create a solid interface with member functions.

If you do so, you can easily change the implementation of the members without disturb any existing link to that object. You have than only to change the internal of a member function but not the existing interface.

Remember that you can also use interface members inside your class which also make the implementation of a complex class maintainable. Example: a constructor that is calling the interface for initializing and destructor that is calling the interface to close objects. Beware not to call a virtual member inside a constructor.

The main reason is that a designer usually has a special purpose in mind for each member of a class he designs, but that purpose is often not clear enough in the first implementation of a class. More importantly, this purpose may not be communicated to others well enough.

If a member variable were declared publicly, but it's purpose not clear, then other developers might write code that use or change them in an inappropriate way, without knowing. Any later clarification of the purpose of this variable will thus be hard to fix, because the entire codebase has to be searched for code accessing the variable.

Using get and set methods lets you add constraints later, without having to bother about others who already accessed a member variable in their code. You just add additional tests, asserts, or conversions in your getters and setters, so that inappropriate access is no longer possible, or at the very least will trigger a visible error that you can fix.

For this to work however, the member variables have to be declared private right from the start, even if intially there is no perceivable advantage in doing so. That is why most developers consider it a good practice to always declare member variables private (or protected) and use getters/setters rather than make them public.

Check out the other solutions for reasons when you would want to use setters/getters. All of them are valid. But as I said, the main point is the possibility that you might find a reason later, rather than the actual existance of one.

There are mainly two reasons why people do not want this, but both are wrong:
1. The cost of adding the getters and setters as well as invoking them (adding at least the ()): This cost is always trivial compared to the rest of the codebase, and modern editors reduce the overhead of typing to a minimum.

2. The performance cost of adding a layer of indirection to access the member variables: Again, this cost is almost always trivial. Performance is a property of an application that should only be considered when the application actually runs and when performance is considered to be an actual problem, and even then, appropriate tools should be used to pinpoint the real bottlenecks, rather than wild guesses.

Even if it should later turn out that direct access is necessary for a specific member variable, changing function calls to direct access only takes a simple find/replace. OTOH, turning an existing public member variable into a property takes a whole lot of work, and this is especially true when you do this for a reason, i. e. you place a restriction, and now have to check every already existing access to see if it's done properly! !