Questions on OOP in MQL5 - page 50
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
Dimitri, in this case you are probably confusing a bit the objectives of the patterns Keeper and Prototype, and all their possible combinations and manifestations. First- Snapshot doesn't necessarily have to copy the whole object, unlike Prototype.
And yes, the need for encapsulation shows up mostly on large projects with lots of people. For toys like most of these, it's a bit of a redundancy.
What it comes down to - to sit there and talk in all seriousness about assigning a value to a variable and then using it. Oh yes - when programming anything on anything, lots of times different values are assigned to different variables and then they are used. But now it's called differently, and now when discussing it, you have to furrow your eyebrows and put on a serious look.
And it's important not to make a mistake, if all the fields are saved, it's Prototype, and if not all of them, it's Keeper, or the guys will laugh.
You're not a member of the "they're installing the internet, we don't need it, we don't need your internet..." sect, are you? ???
1. the custodian, by design, is similar to the pattern they use to store state when typing with changeable content to rollback changes when these changes are not one but several hundred. E.g. photo editor, text editor...
Found it after writing -https://refactoring.guru/ru/design-patterns/memento
2. Basically it's bad practice not knowing and not understanding the subject to criticize something there...
3. How can something you already don't understand become more confusing and difficult to understand?
4. The rest is up to you...
What does the GOP have to do with it?
By any chance, are you not a member of "they install intinet, we don't need it, you intinet" sect? ???
1. the custodian, by design, is similar to the pattern they use to store state when typing with changeable content to rollback changes when these changes are not one but several hundred. E.g. photo editor, text editor...
Found it after writing -https://refactoring.guru/ru/design-patterns/memento
2. Basically it's bad practice not knowing and not understanding the subject to criticize something there...
3. How can something you already don't understand become more confusing and difficult to understand?
4. The rest is up to you...
I'm with you all the way! Thank you for arguing my point... I was lazy))
I would only add in point 1 that the snapshot doesn't necessarily store all the object data, and there can be several branches with hundreds of snapshots of the same object "from different sides". In that case, storing hundreds of copies of unused data is truly the worst practice.
It's come to this - to sit there and talk in all seriousness about how a variable can be assigned a value and then be used. Oh yes - when programming anything in anything, lots of times different values are assigned to different variables, and then they are used. But now it's called differently, and now when discussing it, you have to furrow your eyebrows and put on a serious look.
And it is important not to make a mistake, if all the fields are saved, then it is the Prototype, and if not all, then the Guardian, or the boys will laugh.
Dmitry, I assure you, I would be happy to laugh at you, well, I love it) but in this case, you have exaggerated, even particularly well smiled.
You're just really confused - a SHOT doesn't equal an OBJECT COPY, I've pointed it out to you.
If it's not clear, let me explain for you by example - you have 1000 bytes of object, you need 200 for snapshot, so why copy 800, especially if you have many millions of saved snapshots.
p/s/ And in general. Don't people realize, that patterns is just an elementary example of solving a elementary TYPICAL problem. And in fact the tasks are not elementary, but more complicated. And to solve real problems the patterns are necessary, but often not in pure book form, but adapted to a particular task, possibly combined with each other, possibly with the addition of some improvisation, expressed sometimes in a simplification, if the task allows, or vice versa "weighting" of the realization.
Again, why do you need encapsulation and interfaces - this probably can not be understood if your IQ is below Wasserman, or if you have not participated in real projects, when different parts of the project are changed by different people simultaneously, and not following basic principles of OOPD involves huge costs on catching bugs. Really, why all this for stamping EAs for market))
Sergey Dzyublik:
1. A keeper, similar in design to the pattern used to store state when typing with changeable content to rollback changes when these changes are not one but several hundred. For example a photo editor, a text editor...
2. In fact, it's bad practice not knowing and not understanding the subject to criticize something there...
The key point has been highlighted. It is the modifiable content that is the root of many problems of misuse of OOP. I too was into this for a long time, but with experience gradually comes the understanding. The code where there are a lot of interrelations between objects (pointers) and at the same time these objects are changeable - is a terrible noodle which will not change. Thus, we should strive to make reference objects immutable. Only value-objects must be changeable, i.e. structures and simple types, and pointers as well.
In this case, it is desirable to declare the initial object as a structure, not a class. Then you can change its contents. In this case, of course, no pointer to it will be taken and saved like in the discussed pattern, and this is correct. To change objects you must explicitly refer to their methods, or pass them as an argument to a function, i.e:
or
Not like this:
it looks like we're changing a memento object, but in fact we're changing some other object, which is probably located elsewhere in the program. This creates a side effect. It's the same as changing a global variable in one place and using its value in another place.
I.e. a memento should not store a reference to the original object. It should only store the contents. This is my opinion, but I think I'm not far from the truth )
I'm not claiming my own opinion, probably read somewhere, but imho, there are only two problems in programming: correct program structure and quickly find a good name for a variable, and everything else is done quite easily
I'm serious too.
Thanks, I'll read your patterns
I will wait, in case someone else appears, but only on the level of beginer and trainer questions akademvelopers swoop in ))))
1) The code, which has a lot of interrelations between objects (pointers), and at the same time the objects are changeable, is an absurd noodle, in which the devil can't understand later. Therefore, it is necessary to strive to makethe reference objects unchangeable.
2)Only value-objects, i.e. structures and simple types, and pointers should be changeable.
3) In thiscase, it is desirable to declare the initial object as a structure, not as a class. Then you can change its contents. Of course, you can't take any pointer to it and save it as in the discussed pattern, and this is correct.
4)Objects must be changed by explicitly calling their methods or passing them as an argument into a function.
It looks as if we are changing the memento object but actually it is some other object which is probably located elsewhere in the program. This creates a side effect.
1. It turns out data structure Tree is all from evil...
2. Poor C++ where class == private struct, what to do, we should probably refuse structures and classes.
3. And that's right: no patterns, no sorting by pointers, no memory savings, especially for large objects...
4. We should not forget to forbid using interfaces and template functions, otherwise you won't understand what object you are working with - what a horror...