0

In unversity, my tutor told me always use private variables in class and have a setter and getter function, because it provides better encapsulation. But what is encapsulation? Is there any resons to do so if I know my code is only going to be developed by myself? It's just simpler to use my_obj.var instead of my_obj.set_var(var)!

user762750
  • 159
  • 7
  • 2
    Why don't you ask your tutor what encapsulation is? It's a broad topic that might not be best explained in a short SO answer. – eesiraed Oct 11 '19 at 03:04
  • more practical reasons for making members as private discussed in [here](https://stackoverflow.com/questions/24661886/why-make-class-members-private) on SO . – dorKKnight Oct 11 '19 at 05:45

1 Answers1

0

Encapsulation in the classroom means making an over-engineered 2D point struct. Completely contrived and useless. It does a disservice to the entire concept by teaching it with poor examples.

Encapsulation in the real world is e.g. std::vector which works how you expect and is safe due to not allowing you to tamper with its internals.

In short: no, it's not necessary. It really depends on what you're doing.

In particular, you want encapsulation if your object is handling dynamically-allocated resources directly. So all properly-implemented container types should use encapsulation to prevent you from accidentally breaking it.

But if your type is just a pair of ints or some other raw data, there's really no need.

Specifically, getters and setters should be used if the details of the implementation could potentially change at some later point in the future. E.g. a struct representing a timespan could be represented as seconds:minutes:hours, but could also just be (a lot of) milliseconds. The getters and setters would allow you to turn that into seconds/minutes/etc. without it actually having to be stored that way internally. The operating word here is internal representation.

Cruz Jean
  • 2,761
  • 12
  • 16
  • Your timespan example kind of back fires. Instead of a semantic-free "set_time()" "get_time", better use functions with meaningful names like: "toMilliseconds()" or "fromMilliseconds()". I dare to muse that setters and getters by itself are indicators of a bad design. It produces lines of code with no value, which in the best case is then optimized away again by a compiler. It's a relic from the dark ages of OOP, while nowadays with functional languages becoming more mainstream, OOP classes became somewhat circumspect. – BitTickler Oct 11 '19 at 03:13
  • @BitTickler Accessors are a relic? Well that's a hot take. What's your alternative? – Cruz Jean Oct 11 '19 at 03:18
  • Say you have a type with N elements (a class with N member variables). And you end up typing N pairs of 1 : 1 associated (set_...() , get_...()) functions. What does that tell you about your type, the abstraction or the maintenance? If you expose all the innards of a type in the interface, you cannot change a thing later on and there is no abstraction. In those cases, just use a ``struct`` with trivial members like ``struct Vec3 { float x; float y; float z; };``. If, on the other hand your type is an abstraction, users won't need the elements. Just operations on the new type. – BitTickler Oct 13 '19 at 11:30