0

Suppose we are in this condition:

class C {
    int a, b;
public:
    C(int aa, int bb) { 
        setA(aa);
        setB(bb);
    }
    void setA(int aa) { a = aa; }
    int getA() { return a; }
    void setB(int bb) { b = bb; }
    int getB() { return b; }
    C add(const C c1, const C c2);
};

If in add() I need to access data members, which is the best way to do it? I should use the access functions set and get (created for the client programmer), or I can simply use data members as themself (c1.a, c1.b, c2.a, c2.b) since I am the class designer?

Overflowh
  • 1,103
  • 6
  • 18
  • 40
  • 3
    Do you plan to making `add` `virtual`? – Benjamin Bannier Apr 30 '13 at 11:13
  • in the constructor, no need to call set functions. directly set `a = aa` and `b = bb` – tianz Apr 30 '13 at 11:15
  • @Koushik So. There's nothing illegal in what he does. (There are a couple of questionable issues, like an `add` function which takes three arguments, or the `const C` in a context where `const` is ignored. Or for that matter, having getters and setters for all of the members.) – James Kanze Apr 30 '13 at 12:38
  • @JamesKanze i realized that. thank you. – Koushik Shetty Apr 30 '13 at 13:09
  • A similar question: [What good are public variables then?](http://stackoverflow.com/questions/5168981/what-good-are-public-variables-then/5169119#5169119) – Tony Apr 30 '13 at 14:05
  • @honk: Which kind of advantages I could have in making add virtual? – Overflowh Apr 30 '13 at 16:30
  • @CoderTian: Right, the constructor body is controlled only by the class designer. Thanks. – Overflowh Apr 30 '13 at 16:33
  • 1
    @unNaturhal: I only mentioned part of what I was thinking about: If any of these functions were `virtual` the behavior of e.g. `add` could be changed in derived classes with minimal friction. This would be so easy if e.g. `add` used direct access to the member variables. – Benjamin Bannier Apr 30 '13 at 17:32

4 Answers4

5

You can use either. It depends on whether you want your setters/getters to be just that, or have some additional functionality as well. For example, the getters might also update a counter of how many times that member was accessed, so accessing them through the getter, even inside the class, might make more sense.

Either way, that's not the most important part of the design. You first need to understand what encapsulation really means. Making the members private and providing getters and setters is no better than making them public in the first place (okay, it's a bitter better for debugging purposes, but conceptually it's the same).

Do you really need them?

Also, getters should be made const and you should pass c1 and c2 by const reference.

Luchian Grigore
  • 253,575
  • 64
  • 457
  • 625
  • `Making the members` **private** `and providing getters and setters is no better than making them public in the first place ...` How is one to access a private member without the use of a getter? friendship? But friendship breaks `encapsulation`! I don't understand this point of view you present. – Mushy Apr 30 '13 at 13:25
  • @Mushy if they're public, you can access them directly. My point is that private members coupled with getters and setters also break encapsulation. – Luchian Grigore Apr 30 '13 at 13:30
  • If they are `private` then how would one access them if they do not use `getters` or modify them without the use of `setters`? If `encapsulating a field` is no better than making the members public, ruling out friendship, how are they accessed? – Mushy Apr 30 '13 at 13:33
  • @Mushy making a field private and still giving access to get or set it **doesn't provide encapsulation**. That's my point. – Luchian Grigore Apr 30 '13 at 13:37
  • The OP is looking for good practice when accessing private members. It appears to me that you agree `getters` are the way to access `private` members but then go on to state it breaks encapsulation without providing an alternative method that doesn't. I would like to know what access methodology doesn't break `encapsulation`? Thus, isn't `getter/setter` the best practice? – Mushy Apr 30 '13 at 13:42
  • @Mushy too broad of a discussion, but any good book on OOP will provide the answer. The alternative is to simply disallow access. A class should be self-contained. How you approach it depends on the particular situation. – Luchian Grigore Apr 30 '13 at 13:44
  • Ok, just wondering because I have never read in c++ or Java literature that `accessor/mutator` of `private` members `breaks encapsulation` as if it is a bad thing to use. – Mushy Apr 30 '13 at 13:47
  • @Mushy better explanation here - http://programmers.stackexchange.com/a/21809/42990 - which is why I asked whether he really needs them. But in the case where getters/setters actually do make sense, you can just make the fields public to the same effect. – Luchian Grigore Apr 30 '13 at 14:02
  • @LuchianGrigore: Why I should made getter const and pass arguments as const reference? – Overflowh Apr 30 '13 at 16:35
  • Because the getter doesn't modify the internal state. Furthermore, if it's const, you can call it on const objects. Passing by reference *can* be faster because it doesn't involve copying. – Luchian Grigore Apr 30 '13 at 16:39
2

Just use it directly. Set/get is to access members from outside the class.

Bartosz Marcinkowski
  • 6,651
  • 4
  • 39
  • 69
1

Since add is the member function of class you can directly access private data members. Normally set and get functions are provided for client access.

praks411
  • 1,972
  • 16
  • 23
1

In this particular example I'd simply use the variable names directly.

But there are similar situations where the getters/setters are of much more use.

For example, when the setter (or getter) function is more complicated than just the trivial x = y:

void SetA(int aa){ //a between 0 and 100
    a = std::max(0, std::min(aa, 100));
}

Or when you want to subclass C and overload the getter/setter or add functions.

s3rius
  • 1,442
  • 1
  • 14
  • 26