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?
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.
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.
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.
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.
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.
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.
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.
Related
Given the following class:
class ToggleOutput {
public:
uint32_t count;
ToggleOutput(PARAMETERS) //I've just removed stuff to reduce the code
{
// The code when setting things up
}
void Update() // public method to toggle a state
{
// this method will check if a time period has elapsed
// if the time period has elapsed, toggle an output
// Each time the output is toggled on then count gets incremented
count += 1;
}
};
Later on in the code, several instances of ToggleOutput get created
ToggleOutput outPut_1(PARAMETERS); // Again, PARAMETERS are just the stuff
ToggleOutput outPut_2(PARAMETERS); // I've cut out for brevity.
ToggleOutput outPut_3(PARAMETERS);
ToggleOutput outPut_4(PARAMETERS);
during execution, I want to do stuff, based on the value of the class member variable, count. eg
if (outPut_1.count >= SOMEVALUE)
do_some_stuff();
I have been told that this is not acceptable. To follow the 'tenets of OOP', class methods should be impletmented to interact with class variables from outside of the class, eg the above code would need to become
if (outPut1.getCount() >= SOMEVALUE)
and the class variable count would need to be made private.
Is this true? Or is it acceptable to allow direct access to class variables if required
Or is it acceptable to allow direct access to class variables if required
A lot of research into good software engineering and programmer productivity indicates that it's typically good to hide the details of how something is implemented. If person A writes a class, then s/he has certain assumptions about how the class should work. If person B wants to use the class, then s/he often has different assumptions about how the class should work (especially if person A did not document the code well, or even at all, as is the case all too often). Then person B is likely to misuse the data in the class, which can break how the class methods work, and lead to errors that are difficult to debug, at least for person B.
In addition, by hiding the details of the class implementation, person A has the freedom to complete rework the implementation, perhaps removing the variable count and replacing it with something else. This can occur because person A figures out a better way to implement count, or because count was in there only as a debugging tool and is not necessary to the actual working of ToggleOutput, etc.
Programmers don't write code only for themselves. In general, they write code for other people, that will be maintained for other people. "Other people" includes you five years from now, when you look at how you implemented something and ask yourself, What on earth was I thinking? By keeping the details of the implementation hidden (including data) you have the freedom to change that, and client classes/software don't need to worry about it as long as the interface remains the same.
Basically, member access is a rule you impose to the developers.
It's something you put in place to prevent yourself or another developer using your class from modifying properties that are supposed to be managed only by the class itself and nobody else.
It has nothing to do with security (well, not necessarily anyway), it's more a matter of semantics. If it's not supposed to be modified externally, it should be private.
And why should you care? Well, it helps you keep your code coherent and organized, which is specially important if you are working with a development team or with code that you intent to distribute.
And if you have to document your class, you only have to do so for stuff that is public, as far as the class user is concerned nothing else matters.
This question already has answers here:
Why use getters and setters/accessors?
(37 answers)
Closed 9 years ago.
I've been told not to make my variables public inside a class. I should always make a get and a set function. For example :
class Whatever
{
public:
void setSentence(const std::string &str) { sentence = str; }
void setAnInteger(const int integer) { anInteger = integer; }
std::string getSentence() { return sentence; }
int getAnInteger() { return anInteger; }
private:
std::string sentence;
int anInteger;
};
Why should I do that? Isn't just simply using those variables more convenient? Also, is that a good c++ programming style?
The main reason is to increase encapsulation. If your class exposes those member variables, many functions in your client code will have a dependency towards those variables.
Suppose one day you want want to change the name of those variables, or you want to change the implementation of your class so that the type and number of member variables would be different than the current one: how many functions would be affected by this change? How many functions would you have to re-write (at least in part)?
Right, potentially infinite. You just can't count them all. On the other hand, if you have getters and setters, only those 4 functions will have access to the internal representation of your class. Changing the internal representation won't require any change to the code of your client functions; only those 4 member functions may have to be changed.
In general, encapsulation makes your life easier with respect to future changes. At a certain point in time you may want to log a message every time a certain property is set. You may want to fire an event every time a certain property is set. You may want to compute a certain value on the fly rather than reading it each time from a cache data member, or read it from a database, or whatever.
Having getters and setters allow you to implement any of those changes without requiring to change the client code.
As far as general design philosophy is concerned, there is no "always" or "never" when it comes to implementing accessors versus not implementing accessors that the community as a whole agrees on.
Many will advise you to make all data members private and provide accessors & mutators. Always.
Others will tell you to make data members private if changing them from client code is undesirable, and leave them public otherwise.
Yet others will tell you that classes shouldn't have more than one or so data member at all, and all the data should be encapsulated in yet another object, preferably a struct.
You have to decide for yourself which is right, keeping in mind that this will depend not only on your approach, but also that of the organization for which you work.
If you ask me, my preference is to make everything public until I have a reason not to. Simple. But that's just me.
You write explicit getters and setters as a sane plan for future development. If your class' users are directly accessing its members and you need to change the class in a way that is incompatible with that habit, you have to change every chunk of code that interfaces with you in this way. If you write a getter and setter, the compiler will optimize it to be time-equivalent to direct access (if that is all it does) and you can later change the logic if you need to - without having to change a ton of other code.
When you make get or set method and use it 40 times in your code, you can handle future changes more easily.
Imagine, that you use public variable and use it 40 times in your code. After a month of developing your program, you'll come up with a great idea: What if I divide this variable by 1000 and so I would have better values to calculate with!
Wow, great, but now I have to find every single line, where I use it and change it. If I only had a get method :(
That's the main reason of getters and setters, even if they are very simple, it's better to have it. You will thank yourself once.
Data encapsulation is one of the major principles of OOP. It is the process of combining data and functions into a single unit called class. Using the method of encapsulation, the programmer cannot directly access the data. Data is only accessible through the functions existing inside the class so that the implementation details of a class that are hidden from the user. It's to protect both the caller and the function from accidentally changing the behavior of a method, or from needing to know how a method works.
The textbook-ish answer recalled from me taking the first OOP class was: Get and set methods are used to wrap around private variables. Usually people compare between having get and set or just simply set those variables to be public; in this case, get and set approach is good because it protects those variables from being modified accidentally due to bugs and etc..
People (me when I took that class) might ask "isn't get and set also modify those variables, if so, how is that different than being modified as a public variable".
The rationale is: to have get and set function, you are asking the user or yourself to explicitly specify they want to modify the variable by calling those functions. Without calling those functions, the private variables will be less likely (still possible depends on implementation) modified unwillingly or accidentally.
In short, you should not do that.
In general, I suggest to read Fowler's Refactoring, then you will have a picture what gets hindered by having naked data, and what kind of access aligns well. And importantly whether the whole thing applies to your cases or not.
And as you know pros&cons you can safely ignore "should do/don't" stuff like at start of this answer or others.
Tell, don't ask principle here is often pasted to me when I use getters or setters, and people tell me not to use them.
The site clearly explains what I should and what I shouldn't do, but it doesn't really explain WHY I should tell, instead of asking.
I find using getters and setters much more efficient, and I can do more with them.
Imagine a class Warrior with attributes health and armor:
class Warrior {
unsigned int m_health;
unsigned int m_armor;
};
Now someone attacks my warrior with a special attack that reduces his armor for 5 seconds. Using setter's it would be like this:
void Attacker::attack(Warrior *target)
{
target->setHealth(target->getHealth() - m_damage);
target->setArmor(target->getArmor() - 20);
// wait 5 seconds
target->setArmor(target->getArmor() + 20);
}
And with tell, don't ask principle it would look like this (correct me if i'm wrong):
void Attacker::attack(Warrior *target)
{
target->hurt(m_damage);
target->reduceArmor(20);
// wait 5 seconds
target->increaseArmor(20);
}
Now the second one obviously looks better, but I can't find the real benefits of this.
You still need the same amount of methods (increase/decrease vs set/get) and you lose the benefit of asking if you ever need to ask.
For example, how would you set warriors health to 100?
How do you figure out whether you should use heal or hurt, and how much health you need to heal or hurt?
Also, I see setters and getters being used by some of the best programmers in the world.
Most APIs use it, and it's being used in the std lib all the time:
for (i = 0; i < vector.size(); i++) {
my_func(i);
}
// vs.
vector.execForElements(my_func);
And if I have to decide whether to believe people here linking me one article about telling, not asking, or to believe 90% of the large companies (apple, microsoft, android, most of the games, etc. etc.) who have successfully made a lot of money and working programs, it's kinda hard for me to understand why would tell, don't ask be a good principle.
Why should I use it (should I?) when everything seems easier with getters and setters?
You still need the same amount of methods (increase/decrease vs set/get) and you lose the benefit of asking if you ever need to ask.
You got it wrong. The point is to replace the getVariable and setVariable with a meaningful operation: inflictDamage, for example. Replacing getVariable with increaseVariable just gives you different more obscure names for the getter and setter.
Where does this matter. For example, you don't need to provide a setter/getter to track the armor and health differently, a single inflictDamage can be processed by the class by trying to block (and damaging the shield in the process) and then taking damage on the character if the shield is not sufficient or your algorithm demands it. At the same time you can add more complex logic in a single place.
Add a magic shield that will temporarily increase the damage caused by your weapons for a short time when taking damage, for example. If you have getter/setters all attackers need to see if you have such an item, then apply the same logic in multiple places to hopefully get to the same result. In the tell approach attackers still need to just figure out how much damage they do, and tell it to your character. The character can then figure out how the damage is spread across the items, and whether it affects the character in any other way.
Complicate the game and add fire weapons, then you can have inflictFireDamage (or pass the fire damage as a different argument to the inflictDamage function). The Warrior can figure out whether she is affected by a fire resistance spell and ignore the fire damage, rather than having all other objects in the program try to figure out how their action is going to affect the others.
Well, if that's so, why bother with getters and setters after all? You can just have public fields.
void Attacker::attack(Warrior *target)
{
target->health -= m_damage;
target->armor -= 20;
// wait 5 seconds
target->armor += 20;
}
The reason is simple here. Encapsulation. If you have setters and getters, it's no better than public field. You don't create a struct here. You create a proper member of your program with defined semantics.
Quoting the article:
The biggest danger here is that by asking for data from an object, you
are only getting data. You’re not getting an object—not in the large
sense. Even if the thing you received from a query is an object
structurally (e.g., a String) it is no longer an object semantically.
It no longer has any association with its owner object. Just because
you got a string whose contents was “RED”, you can’t ask the string
what that means. Is it the owners last name? The color of the car? The
current condition of the tachometer? An object knows these things,
data does not.
The article here suggests here that "tell, don't ask" is better here because you can't do things that make no sense.
target->setHealth(target->getArmor() - m_damage);
It doesn't make sense here, because the armor has nothing in relation to health.
Also, you got it wrong with std lib here. Getters and setters are only used in std::complex and that's because of language lacking functionality (C++ hadn't had references then). It's the opposite, actually. C++ standard library encourages usage of algorithms, to tell the things to do on containers.
std::for_each(begin(v), end(v), my_func);
std::copy(begin(v), end(v), begin(u));
One reason that comes to mind is the ability to decide where you want the control to be.
For example, with your setter/getter example, the caller can change the Warrior's health arbitrarily. At best, your setter might enforce maximum and minimum values to ensure the health remains valid. But if you use the "tell" form you can enforce additional rules. You might not allow more than a certain amount of damage or healing at once, and so on.
Using this form gives you much greater control over the Warrior's interface: you can define the operations that are permitted, and you can change their implementation without having to rewrite all the code that calls them.
At my point of view, both codes do the same thing. The difference is in the expressivity of each one. The first one (setters anad getters) can be more expressive than the second one (tell, don' ask).
It's true that, when you ask, you are going to make a decision. But it not happens in most part of times. Sometimes you just want to know or set some value of the object, and this is not possible with tell, don't ask.
Of course, when you create a program, it's important to define the responsabilities of an object and make sure that these responsabilities remains only inside the object, letting the logic of your application out of it. This we already know, but if you need ask to make a decision that's not a responsability of your object, how do you make it with tell, don't ask?
Actually, getters and setters prevails, but it's common to see the idea of tell, don't ask together with it. In other words, some APIs has getters and setters and also the methods of the tell, don't ask idea.
From: http://www.parashift.com/c++-faq-lite/basics-of-inheritance.html#faq-19.9
Three keys: ROI, ROI and ROI.
Every interface you build has a cost and a benefit. Every reusable
component you build has a cost and a benefit. Every test case, every
cleanly structured thing-a-ma-bob, every investment of any sort. You
should never invest any time or any money in any thing if there is not
a positive return on that investment. If it costs your company more
than it saves, don't do it!
Not everyone agrees with me on this; they have a right to be wrong.
For example, people who live sufficiently far from the real world act
like every investment is good. After all, they reason, if you wait
long enough, it might someday save somebody some time. Maybe. We hope.
That whole line of reasoning is unprofessional and irresponsible. You
don't have infinite time, so invest it wisely. Sure, if you live in an
ivory tower, you don't have to worry about those pesky things called
"schedules" or "customers." But in the real world, you work within a
schedule, and you must therefore invest your time only where you'll
get good pay-back.
Back to the original question: when should you invest time in building
a protected interface? Answer: when you get a good return on that
investment. If it's going to cost you an hour, make sure it saves
somebody more than an hour, and make sure the savings isn't "someday
over the rainbow." If you can save an hour within the current project,
it's a no-brainer: go for it. If it's going to save some other project
an hour someday maybe we hope, then don't do it. And if it's in
between, your answer will depend on exactly how your company trades
off the future against the present.
The point is simple: do not do something that could damage your
schedule. (Or if you do, make sure you never work with me; I'll have
your head on a platter.) Investing is good if there's a pay-back for
that investment. Don't be naive and childish; grow up and realize that
some investments are bad because they, in balance, cost more than they
return.
Well, I didn't understand how to correlate this to C++ protected interface.
Please give any real C++ examples to show what this FAQ is talking about.
First off, do not ever treat any programming reference as definitive. Ever. Everything is somebody's opinion, and in the end you should do what works best for you.
So, that said, what this text is basically trying to say is "don't use techniques that cost you more time than they save". One example of the "protected interface" they're describing is the following:
class C {
public:
int x;
};
Now, in Java, all the Java EE programming books will tell you to always implement that class like this:
class C {
public:
int getX() { return x; }
void setX(int x) { this.x = x; }
private:
int x;
};
... that's an implementation of proper encapsulation (technical term: simplifying a little, it means minimizing sharing between discrete parts). The classes using your code are concerned that you have some way to get and set an integer, not that it's actually stored as an int inside the class. So if you use accessor methods, you're better able to change the underlying implementation later: maybe you want it to read that variable from the network?
However, that was a large amount of extra code (in terms of characters) and some extra complexity to implement that. Doing things properly actually has a cost! It's not a cost in terms of correctness of the code - directly - but you spent some number of minutes doing it "better" that you could have spent doing something else, and there is a nonzero amount of work involved in maintaining everything you write, no matter how trivial.
So, what is being said in this passage is in my mind good advice: always double-check that when you go to do something, you're going to get more out of it than what you put in. Sanity check that you are not following an ideal to the detriment of your actual effectiveness as a programmer or a human being.
That's advice that will serve you well in any programming language, and in any walk of life.
From your quote above, the guy sounds like a pedantic jerk :)
Looking at the previous entries in his FAQ, he's really saying the following:
1) A class has two distinct interfaces for two distinct sets of clients:
It has a public interface that serves unrelated classes
It has a protected interface that serves derived classes
2) Should you always go to the trouble of creating two different interfaces for each class?
3) Answer: "no, not necessarily"
Sometimes it's worth the extra effort to create protected getter and setter methods, and make all data "private"
Other times - he says - it's "good enough" to make the data itself "protected". Without doing all the extra work of writing a bunch of extra code, and incurring the consequent size and performance penalties.
Sounds reasonable to me. Do what you need to do - but don't go overboard and do a bunch of unnecessary stuff in the name of "theory".
That's all he's saying - use good judgement, and don't go overboard.
You can't argue with that :)
PS:
FAQ's 19.5 through 19.9 in your link deal with "derived classes". None of this discussion is relevant outside of the question "how should I structure base classes for inheritance?" In other words, it's not a discussion about "classes" in general - only about "how should a super class best make things visible to it's subclasses?".
I've read a lot of guides that explain why I should use "private" and the answer is always "Because we don't want anyone else setting this as something". So, let me ask the following questions:
Assuming that I want to have a variable that is set-once (perhaps something like a character name in a video game, ask once, then it's set, and then you just use the get variable(edit:function) for the rest of the game) how do I handle that one set? How would I handle the get for this as well?
What is the actual advantage of using a private access modifier in this case? If I never prompt the user to enter the name again, and never store information back to class.name shouldn't the data remain safe (moderately, assuming code works as intended) anyways?
I hope someone will help me out with this as the explanations I've googled and seen on here have not quite put my thoughts to rest.
Thanks!
The access specifiers mainly serve to denote the class interface, not to effectively limit the programmer's access or protect things. They serve to prevent accidental hacking.
If something is set once, then you should try to set it when it is created, and make it const.
If the interface doesn't need to be especially clear (for example, if few people need to learn it) then it doesn't make sense to spend effort engineering it. Moreover changes that don't make much difference in how the interface is used can be applied later. The exposed variable can be changed to a getter/setter using simple search-and-replace.
If it were a published binary interface, then you would want to get it right the first time. But you're just talking about the internals of your program.
And it's fairly unlikely that anyone will reset the player name by accident.
I won't try to justify the private set method as that sounds a bit weird to me. You could handle the one set by using a friend declaration. But then why would you define a setter when the friend could just set the value directly?
I generally avoid setters if I can at all manage it. Instead I prefer provide facility to set member variables via the constructor. I am quite happy to provide getters if they make sense.
class player_character_t {
std::string name_;
public:
player_character_t(std::string const& name)
: name_ (name)
{
}
std::string const& name() const { return name_; }
};
This forces you to delay construction of the object until you have all the information you require. It simplifies the logic of your objects (ie they have a trivial state diagram) and means you never have to check is something is set before reading it (if the object exists, it is set properly).
http://en.wikipedia.org/wiki/State_diagram
Marking things as private helps prevent accidents. So when you make a mistake and it is no longer the case that the "code works as intended" the compiler may help you detect it. Likewise const can be a big help in detecting when you are using objects incorrectly.
It's that last parenthetical that is important: assuming code works as intended.
In my mind it's similar to permissions in Linux systems. You know the root password and you can delete any file, but you don't stay logged in as root so you don't do anything by accident. Similarly, when you have a private variable characterNameString, and someone (or you) later tries to give it a new value, it will fail. That person will have to go look at the code and see that it's marked private. That person will have to ask themselves "why is this private? Should I be modifying it? Should I be doing this another way?" If they decide they want to, then, they can. But it prevents silly mistakes.
Don't confuse the private and the public interfaces of the class. In theory these are completely different interfaces, and this is just a design feature of C++ that they're located physically in the same class declaration.
It's perfectly ok to have a public getter/setter when the object property should be exposed via the public interface, so there is no rule such as 'setter is always private'.
More on that topic in the (More) Exceptional C++ books by Herb Sutter. It's an absolutely neccessary reading for someone who wants to understand C++ and be proficient with it.
If you have doubts over deciding whether to use getter/setters over the class variables, there are numerous explanations on the internet why getters/setters are better.
If the variable is 'write once then forever read only' I'd recommend making it a const member that is initialized during construction. There's no value in a private 'setter' function because it won't be used. Also you avoid people using the setter function to set the name when it's never meant to be set.
For example:
class Player
{
private:
const std::string m_name;
public:
Player(const std::string& name) : m_name(name) {}
};
Private getters and setters all make sense when the data in question involves several variables, have additional constraints you want to make sure you adhere to, and these operations are done several times in your class. Or when you plan further modifications to the data model and wish to abstract operations on the data, like using std::vector but planning to make it std::map or similar cases.
For a personal example, I have a smart pointer implementation with a private reset(T*, int*) method that is essentially a setter for the stored object and its reference count. It handles checking validity of objects and reference counts, incrementing and decrementing reference counts, and deleting objects and reference counts. It is called eight times in the class, so it made perfect sense to put it into a method instead of just screwing around with member variables each time, slowing programming, bloating code and risking errors in the process.
I am sure private getters can also make sense if you are abstracting the data from the model and/or you have to implement error checking, for example throwing instructions if the data is NULL instead of returning NULL.