2

I am still new to C++ and OOP programming, and I was just wondering about something curious. I have a class let's name it Foo, with some private members. My question is: the Foo objects don't "pass data" to other objects during their lifespan. They receive data, do things, and save new data to file. That means, only Foo objects will access Foo private members. Is it wrong to implement private getters and setters? Or should I use direct access? Pseudo code below:

Is this okay?

class foo
{
  private:
    string a;
    string b;
    string c;
    void setA(string A){this->a=A;}
    string getA()const{return this->a;
    void setB(string B){this->b=B;}
    string getB()const{return this->b;
    void setC(string C){this->c=C;}
    string getC()const{return this->b;
  public:
    //many omitted methods//
    void Method(); //<-- this method does things and calls private getters and setters to modify private members
}

In main:

{
Foo obj=....;
obj.Method();
}

Or should I:

class foo
{
  private:
    string a;
    string b;
    string c;
  public:
    //many omitted methods//
    void Method();
}

void foo::method()
{
    string s1;
    //initialize s1;
    this->a=s1; //operation example
    std::cout<<"A equals: "<< this->a;
}

Not sure if I explained my concerns in simple way. Thank you in advance for your replies and help.

Giulio Paoli
  • 85
  • 11
  • 2
    At some point you have to write the code that access the members themselves. I don't see the point in putting it off tbh. Personally I try to avoid *public* getters and setters as they can break encapsulation. – Galik Feb 20 '18 at 12:55
  • This is more a matter of opinion and therfore is not really suited for this format. Here is a nice article discussing your question : https://www.quora.com/Are-we-supposed-to-use-getters-and-setters-for-every-instance-variable-in-real-life-Java-programs-or-is-it-just-something-they-tell-you-at-the-university – Rann Lifshitz Feb 20 '18 at 12:55
  • I'm thinking about implementing direct access: am I wrong if I say that declaring those getters and setters `inline` will produce the same result as a direct access? – Giulio Paoli Feb 20 '18 at 13:02
  • I have used private setters/getters, but only very limited situations where changing a value also needs to send an event that the value changed. The setter handled that additional behavior. Otherwise, for C++, there's no need to treat a member variable as some sort of Java Bean kind of value, let alone with private getters/setters. – Eljay Feb 20 '18 at 13:03
  • @GiulioPaoli that really is up to the compiler what happens. inline only compels the compiler to be more aggressive in inlining (usually it takes away the max function body byte limit) – Neijwiert Feb 20 '18 at 13:05
  • @GiulioPaoli Maybe [this link might be helpful](https://stackoverflow.com/questions/8983709/why-would-you-declare-getters-and-setters-method-private)? (It is for Java, but the philosophy should be the same) – Arnav Borborah Feb 20 '18 at 13:06
  • @ArnavBorborah Thank you for providing that link. It was helpful and made me realize that I don't really need those getters and setters, in my own strict case. Thanks. – Giulio Paoli Feb 20 '18 at 13:18

3 Answers3

4

Writing private "getters" and "setters" is pointless, unless you are exploiting polymorphism in some funny way.

Setting up your member variables via a constructor is the best thing to do, and making the members const prevents their unintentional modification.

Avoid "setters" whenever possible regardless of their accessibility as they do little more than circumvent encapsulation.

Bathsheba
  • 231,907
  • 34
  • 361
  • 483
  • 1
    Aren't setters useful for validation of setting? – Giulio Paoli Feb 20 '18 at 12:58
  • @GiulioPaoli - What is the purpose of validation inside the class itself? – StoryTeller - Unslander Monica Feb 20 '18 at 13:00
  • @StoryTeller well the validation would only have to be at one location – Neijwiert Feb 20 '18 at 13:00
  • 1
    I wouldn't say private setters are _useless_. Suppose one has to validate their member fields every time they assign to them. Putting this check everywhere would be repetitive and is best moved to a setter, private or public. A plain setter is pointless, however. – Arnav Borborah Feb 20 '18 at 13:01
  • @Neijwiert - You misunderstood me. Why would code at class scope set stuff that may break the class's own constraints? – StoryTeller - Unslander Monica Feb 20 '18 at 13:01
  • @ArnavBorborah: I'd say that's an XY problem. – Bathsheba Feb 20 '18 at 13:01
  • @StoryTeller That's a good point, I'm trying to figure out a way where that wouldn't be the case, but I can't really think of one right now. Maybe if the class is being developed by multiple people and to make sure that everybody keeps to the pre-set constraints or something like that? – Neijwiert Feb 20 '18 at 13:03
  • @StoryTeller I see your point, and I am starting to think that they may be superfluous – Giulio Paoli Feb 20 '18 at 13:04
  • @Neijwiert - Maybe. It's actually not validation we want, but assertions (to check for programming mistakes while in development). I would consider a private setter with an assertion justified. A private setter with validation that goes to a production build... well... – StoryTeller - Unslander Monica Feb 20 '18 at 13:06
  • @StoryTeller I agree, assertions would be the only justified case here. – Neijwiert Feb 20 '18 at 13:07
  • 4
    And as for private getters. The redundant office of redundancy comes to mind. – StoryTeller - Unslander Monica Feb 20 '18 at 13:07
  • @StoryTeller The only case I can think of is if the "setter" doesn't validate the value passed to it, but maybe applies some sort of computation/other function to it, which is all moved to a single function to avoid repetition. But now I am unsure if such a function would still be considered a setter or not. (Since it doesn't just set the value passed to it after validation to the member, but modifies it and then sets the member variable). – Arnav Borborah Feb 20 '18 at 13:08
  • 2
    I'd only ever allow `public` and `protected` single member variable setters to assert. And writing a setter that changed other member variables in order to regain consistency would be an exercise in obfuscation. – Bathsheba Feb 20 '18 at 13:09
  • @StoryTeller: Indeed. Should a set of redundant sets contain itself? – Bathsheba Feb 20 '18 at 13:17
  • @ArnavBorborah - "Just setters" are a code smell, and are to be avoided. Bathsheba makes an excellent point against them. – StoryTeller - Unslander Monica Feb 20 '18 at 13:17
  • @Bathsheba - Your'e the mathematician here, so you tell me. Russell's paradox always made me go cross-eyed in college. – StoryTeller - Unslander Monica Feb 20 '18 at 13:18
2

I'm not the most experienced C++ developer, but from my point of view, using direct access is not a bad practice and it will require less time to write. On the other hand, having such members in your interface makes it clear that only the Foo objects could read Foo's private members, so both ways are acceptable.

linSESH
  • 388
  • 3
  • 12
2

The main point of having getters and setters is controlling access to the class members in a flexible and extensible way. You don't get anything from creating getters and setters if you know they will never be used by external clients of the class, so I would advice to not write them at all.

They will only clutter your source files and make your code harder to read.


By they way, you don't need to use this everytime you want to access a member:

class foo {
  private:
    string a;
    string b;
    string c;
  public:
    //many omitted methods//
    void Method();
}

void foo::method() {
    string s1;
    a=s1; 
    std::cout<<"A equals: "<< a;
}
amc176
  • 1,514
  • 8
  • 19
  • My professor always taught me to use the `this` keyword everytime to avoid ambiguity. Thank you for your reply, by the way! – Giulio Paoli Feb 20 '18 at 13:08
  • @GiulioPaoli: But there's no ambiguity. Tell your professor to learn the language correctly, with more tact than I would, naturally. – Bathsheba Feb 20 '18 at 13:12
  • 2
    I will. Let me have my degree, first. – Giulio Paoli Feb 20 '18 at 13:13
  • @GiulioPaoli ;-) Then drop that 2 character indentation style that no sane person on a collaborative project uses. – Bathsheba Feb 20 '18 at 13:14
  • Ahahah, I don't usually indent like this! Didn't care that much about indentation since the question is pretty straight-forward. I use the old-hate-but-often-used tabular indentation :D – Giulio Paoli Feb 20 '18 at 13:17