I'm coming at this from a standpoint of encapsulation. Newbies are told "don't make your data members public", but don't really understand the reason why that's generally bad. Nor do they really grasp the concept of encapsulation and how it's used.
Feel free to disregard my advice and do things your own way. I'm posting merely to try and give you insight as to why a real-world program would not be written this way.
The whole point to encapsulation is that you keep specific classes isolated so that no outside code needs to understand their inner workings. Instead, a simplified interface of abstracted concepts is given to outside code.
When a class is properly encapsulated, it makes it difficult to "misuse". Compare the dangers of using raw char arrays for strings vs. the std::string class. With char arrays you need to be mindful of buffer overflows, memory management, making sure your strings are null terminated, etc, etc. But with std::string, all of that is handled "under the hood", and you are given a simple, intuitive interface to interact with the class.
All of this outside code can now use std::string because of its simple interface... and none of it
has to care about how the class works internally. As long as it works as described... the means by which it accomplishes it doesn't matter.
This is a powerful concept in programming because it allows for code reusability, easier testing, easier debugging, and just in general improved organization of the code and logic.
This is why you keep your data members private. If they're private you have full control over the state of the object. It keeps the class's code isolated. If other areas of the code and stick their dirty little fingers in and muck up the data, then it's difficult/impossible to ensure the class will always work.
By contrast... if you have public members (or a dozen friends), then your class is no longer encapsulated. If you start having problems with your Account class... now you don't know whether the problem is coming from your Account code or your MainMenu code, or your <insert other friend here> code.
If the class was encapsulated... you'd know the problem was in your Account code because that's the only code that can access it. It makes the problem much easier to find and fix.
|There is actually a good reason for it in my actual program. I want createAccount to be able to store values in the private members of account and they need to be validated first|
Input validation could be done in the setter. That's kind of what setters are for. If a setter is just going to blindly assign a data member even if what is being assigned is wrong... then you're violating encapsulation and once again, there is no point in using getters/setters and you might as well just make the data public to begin with.
The whole point with having encapsulation is that no data members are ever
invalid in the object. You keep everything private, and everything valid... so that you know the object is always
in a good state. Or at least in an expected state.
If you let MainMenu access Account's members, Account can no longer guarantee that it is always going to be valid, because it's at the mercy of MainMenu.
EDIT: Also... instead of MainMenu getting the input... Account could be doing it. Friendship should only be used between very tightly-knit classes. Classes that cannot exist without one another.
Here... there is no reason for Account to be bound to MainMenu, so there is no reason for them to be friends.
|I have to do this many times for different member variables so it would make the code a lot shorter |
So why not remove the getters/setters entirely and make the data public? That's even shorter
code. </rhetorical. I'm not actually trying to get you to do this.. just pointing out a hole in your logic>
Encapsulation is not about writing shorter code. It's about writing stronger code.