CODEWITHSUNDEEP
c++oopclassprivate
darko
darko

Reputation: 2458

Examples of why declaring data in a class as private is important?

I understand that only the class can access the data so therefore it is "safer" and what not but I don't really understand why it is such a big deal. Maybe it is because I haven't made any programs complex enough where data could accidentally be changed but it just a bit confusing when learning classes and being told that making things private is important because it is "safer" when the only time I have changed data in a program is when I have explicitly meant to. Could anyone provide some examples where data would have been unintentionally changed had that data not been private?

Upvotes: 3

Views: 409

Answers (7)

Katherina
Katherina

Reputation: 2223

When you are on a project where 2 or more people are working on the same project, but you work lets, say, 2 people work on Mondays, 2 on Tuesdays, 2 on Wednesdays, etc. The next people that will continue the project won't have to go bother the other coders just to explain what/when/why it has been that way. If you know TORTOISE you will see it's very helpful.

Upvotes: 0

Jesse Emond
Jesse Emond

Reputation: 7480

Let's say you have a BankAccount class where you store a person's NIP and cash amount. Let's put all the fields public and see what could go wrong:

class BankAccount
{
public:
    std::string NIP;
    int cash;
};

Now, let's pretend that you leave it this way and use it throughout your program. Later on, you find a nasty bug caused by a negative amount of cash (whether it is from calculations or simply an accident). So you spend a couple of hours finding where that negative amount came from and fix it.

You don't want this to happen again, so you decide to put the cash amount private and perform checks before setting the cash amount to avoid any other bugs like the previous one. So you go like this:

class BankAccount
{
public:
    int getCash() const { return cash; }
    void setCash(int amount) 
    {
        if (amount >= 0)
            cash = amount;
        else
            throw std::runtime_exception("Cash amount is negative.");
    }

private:
    int cash;
}

Now what? You have to find all the cash references and replace them. A quick and dirty Find and Replace won't fix it so easily: you must change accessors to getCash() and setters to setCash. All this time fixing something not so important that could have been avoided by hiding the implementation details within your class and only giving access to the general interface.

Sure, that's indeed a pretty dumb example, but it happened to me so many times with more complex cases(sometimes the bug is much harder to find) that I've really learned to encapsulate as much as I can. Do your future-self and the viewers of your code a favor and hide private members, you never know when your "implementation details" will change.

Upvotes: 0

quasistoic
quasistoic

Reputation: 4687

The moment you start collaborating with other people on code, you'll appreciate the clarity and security of keeping your privates private.

Say you've designed a class that rotates an image. The constructor takes an image object, and there's a "rotate" method that will rotate the image the requested number of degrees and return it.

During rotation, you keep member variables with the state of the image, say for example a map of the pixels in the image itself.

Your colleagues begin to use the class, and you're responsible for keeping it working. After a few months, someone points out to you a technique that performs the manipulations more efficiently without keeping a map of the pixels.

Did you minimize your exposed interface by keeping your privates private?

If you did, you can swap out the internal implementation to use on the other technique, and the people who've been depending on your code won't need to make any changes.

If you didn't, you have no idea what bits of your internal state your colleagues are depending on, and you can't safely make any changes without contacting all of your colleagues and potentially asking them to change their code, or changing their code for them.

Is this a problem when you're working alone? Maybe not. But it is a problem when you've got an employer, or when you want to open-source that cool new library you're so proud of.

Upvotes: 3

Xeo
Xeo

Reputation: 131789

You don't want someone to suddenly fiddle with your internals, no? So do C++'s classes.

The problem is, if anyone can suddenly change the state of a variable that is yours, your class will screw up. It's as if someone suddenly fills your gut with something you don't want. Or exchanges your lung for someone elses.

Upvotes: 0

ChrisWue
ChrisWue

Reputation: 19020

Depends what you mean by "unintentional changes". All code is written by someone so if he is changing a member variable of a class then the change is intentional (at least from his side). However the implementor of the class might not have expected this and it can break the functionality.

Imagine a very simple stack:

class Stack
{
    public:
        int Items[10];
        int CurrentItemIndex;
}

Now CurrentItemIndex points to the index which represents the current item on top of the stack. If someone goes ahead and changes it then your stack is corrupted. Similarly someone can just write stuff into Items. If something is public then it is usually a sign that it is intended for public usage.

Also making members private provides encapsulation of the implementation details. Imagine someone iterates over stack on the above implementation by examining Items. Then it will break all code if the implementation of the stack gets changed to be a linked list to allow arbitrary number of items. In the end the maintenance will kill you.

The public interface of a class should always be as stable as possible because that's what people will be using. You do not want to touch x lines of code using a class just because you changed some little detail.

Upvotes: 5

Luke
Luke

Reputation: 1870

Generally you want to hide "data" (make vars private) so when people that aren't familiar with the class don't access data directly. Instead if they use Public modifiers to access and change that data.

Eg. accessing name via public setter could check for any problems and also make first character upper case Accessing data directly will not do those checks and possible changes.

Upvotes: 0

Chris Dennett
Chris Dennett

Reputation: 22721

When you make a library that other people use, you want to show the most basic sub-set of your code possible to allow external code to interface with it. This is called information hiding. It would cause more issues if other developers were allowed to modify any field they wanted, perhaps in an attempt of performing some task. An attempt that would cause unspecified program behaviour.

Upvotes: 1

Related Questions