Questions on OOP in MQL5 - page 49
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
And the point of these wild mind games? The "purpose" (in quotes, because... gladiolus) of the pattern is to"without breaking encapsulation, fix and preserve the internal state of the object" (in quotes, because quoting). But you can't do without the setState() method. So where is saving of encapsulation here? To write two more methods for each private field... Yeah... cool, the encapsulation is preserved.
And be honest, will you use this approach in practice? I doubt it. In practice, you will make it explicit and transparent - for example, a structure with the same set of fields and a couple of methods for saving and restoring. And then the encapsulation will be really preserved, there will be only two new methods: for saving the state and for restoring.
OK, I'll save it, I needed to test the principle of work, maybe this is what I was looking for - one code for tester and for working EA, which can save its state, and in the tester on the contrary not to waste resources on "extra gestures" - part of such pattern can be covered by #ifdef -ami ;)
I'm trying to understand the meaning of this crammer with the keeper, but I don't see any particular use. In fact, it's bad programming practice through creation of side-effects. When you change one object you change another. As a result, the code becomes tangled and difficult to understand. It's better to strive for code purity, imho.
What prevents you from simply copying an object into another object and then copying it back? It is essentially the same thing, only more correct and clearer.
If this singleton has both setters and getters at the same time (i.e. allows to change its state and read it), it is equivalent to working with global variables. And every programmer knows that working through changing global state is evil. But the singleton somehow does not count )
I'm trying to understand the meaning of this custodian thing, but I don't see any particular benefit. In fact, it is a bad programming practice by creating side-effects. When you change one object, you change another. As a result the code becomes tangled and difficult to understand. It's better to strive for code purity, imho.
It's simpler, I'm learning the technical stuff
I'm used to evaluating the condition of an automated system from the viewpoint of a finite state machine, and I always want to keep a "snapshot" of the system state as a reserve ))))
I am more accustomed to evaluating the state of an automated system from the perspective of a finite state machine, and this always makes me want to be able to keep a "cast" of the system's state as a backup )))
It's just that such an implementation is overly complicated and confusing, in my opinion.
The aim is clear, it's just too complicated and confusing, in my opinion.
Alas, that's how people are - until I get my kicks and bumps in the ass, I'm unlikely to get it)))
Alas, that's the way people are - until I get my own knocks and bumps, I'm unlikely to get it)))
There's nothing wrong with someone studying these patterns - it's great - brain exercises, etc. etc. But on closer inspection it turns out to be some infernal fake, some meme to pull suckers away from reality, just like learning visual BASIC by writing console applications.
Studying these patterns is interesting, if only from the point of view of learning someone's cockroaches - what they are in nature.
And if we're really approaching the task of preserving an object's state, the way is to make it possible to copy one object to another, whichever one likes, be it a simple method or an overload = overloading. And after that, you might not want to encapsulate this feature.
And if we really approach the task of preserving the state of an object, the way to do it is to make it possible to copy one object to another, whichever one likes, whether it's just through a method or through an overload =. And after that, you might not want to encapsulate this feature.
For real, any technical system can be designed based on 3 basic principles:
- conforms to the latest standard
- our grandfathers built it that way, no need to reinvent the wheel
- You should not build it out of shit and sticks and then modify it
)))
Just kidding, I have time to read and play around with the options, I take advantage of it, as well as the opportunity to get a quick explanation of the unclear points on the forum ;)
I'm trying to understand the meaning of this custodian thing, but I don't see any particular benefit. In fact, it is a bad programming practice by creating side-effects. When you change one object, you change another. As a result, the code becomes tangled and difficult to understand. It's better to strive for code purity, imho.
What prevents you from simply copying an object into another object and then copying it back? It's virtually the same thing but more correct and clearer.
If this singleton has both setters and getters at the same time (i.e. allows to change its state and read it), it is equivalent to handling global variables. And every programmer knows that working through changing the global state is evil. But the singleton somehow does not count )
I suppose this is a typical point of view of a programmer who has never had anything to do with serious large-scale projects? Forgive me for being blunt, but I don't see any other explanation for calling the basics bad practice )
There's nothing wrong with someone studying these patterns, it's great - brain exercises, etc. etc. And then, on closer inspection, it turns out to be some kind of infernal fake, some kind of meme to lure suckers away from reality, just like learning visual BASIC by writing console applications.
Studying these patterns is interesting, if only from the point of view of learning someone's cockroaches - what they are in nature.
And if we're really approaching the task of preserving an object's state, the way is to make it possible to copy one object to another, whichever one likes, be it a simple method or an overload = overloading. And beyond that, maybe the desire to encapsulate this feature will fall away.
Dmitry, probably in this case you confuse a bit tasks of patterns Keeper and Prototype, and all their possible combinations and manifestations. The 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 tasks here, it's overkill, of course)
1) I'm trying to figure out the point of this custodian thing, but I don't see the benefit.
2) It's essentially bad programming practice to create side-effects.
3) When you change one object, you change another. As a result, the code becomes tangled and difficult to understand. It's still better to strive for code purity, imho.
4) What prevents you from simply copying an object into another object and then copying it back? In essence it is the same but more correct and clear.
If this singleton has both setters and getters at the same time (i.e. allows to change its state and read it), it is equivalent to working with global variables. And every programmer knows that working through changing the global state is evil. But the singleton somehow does not count )
Aren't you part of "they install it, we don't need it, it's yours ..." 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...