Errors, bugs, questions - page 1057
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
The wallet is just a special case. And no one is stopping it from being placed in the private part.
In another case, you may need to access the parent class variable of someone else's object.
And this is up to the programmer to decide whether to allow it or not. And the compiler must ensure that the program works correctly.
That's the point, if this very different case occurs to you, it means that your architecture is conceptually wrong and potentially dangerous.
In C++, the concept of so-called friendly classes was introduced at some time in an unfortunate way. It's like if one class knows how another class is organized, it can safely work with its internal data. The practice of using it by thousands of programmers around the world has shown that it is a dangerous thing, creating more problems than solving them, so it is abandoned in modern languages like Java and C#.
This feature was unpleasantly surprising. It's definitely bullshit if the compiler allows to change the private field of someone else's instance. We should post it to Service Desk.
I don't understand: why do you want to limit yourself so much?
Do you think it will automatically make your programme safer?
It won't! On the contrary.
It's the unnecessary restrictions that will make you write it that way someday:
You know a thing or two about OOP, but you don't understand it yet.
Look:
Is it surprising that I closed the "wallet" variable, despite the fact that the original idea of the class is to make its wallet available to everyone? But if everyone takes as much as he wants, we'll lose money and that's impossible. Now function GetMoney allows it, but after adding a few lines, it won't allow to take more money. Now imagine that the class Maecenas is accessed by dozens of different objects asking for money. If the wallet variable is opened, then each of these objects would also have to control (i.e. have their own implementation) to check if they have enough money. And if at least one of them does not, it risks getting a negative value instead of zero, which would mean that it asked for money and ended up owing money as well.Mate, I see you know a thing or two about OOP, but you haven't grasped the essence of it yet.
Look:
Is it surprising that I closed the variable "purse", despite the fact that the original idea of the class is to make its purse available to everyone? But if everyone takes as much as he wants, we'll lose money and that's impossible. Now function GetMoney allows it, but after adding several lines, it won't allow to take more money. Now imagine that the class Maecenas is accessed by dozens of different objects asking for money. If the wallet variable is opened, then each of these objects would also have to control (i.e. have their own implementation) to check if they have enough money. And if at least one of them doesn't, it risks getting a negative value instead of zero, which would mean that it asked for money and ended up owing money as well.I had nothing against the private wallet. The conversation started with this:https://www.mql5.com/ru/forum/1111/page1072#comment_589657
This is correct. Class B accesses external class A and wants protected variables of class A to be available to it. I don't understand the logic here.
What's logic got to do with it?
http://alenacpp.blogspot.com/2006/03/blog-post_11.html
The protected modifier is a whore. Rarely is it really needed.
True encapsulation implies data privacy.
Can you tell me if you want to select the first character in pos - should I put 1 or 0 in pos? Is it indexed like in arrays?
Can you tell me if you want to select the first character in pos - should I put 1 or 0 in pos? Is it indexed as in arrays?