Questions on OOP in MQL5 - page 55
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
You're stuck in the minutiae. Uninteresting. The main point of the "keeper" pattern discussion here was that it sort of promises encapsulation preservation, but is implemented by creating a couple of public methods for each field. Funny how you didn't catch the most important message.
I'm not stuck, I'm trying out of respect for you as an interlocutor to make sense of your words and unravel your self-contradictions. Apparently in vain.
I don't think anyone here is interested in your "holy patterns" froth either.
Everything here is clear, specific and canonical. There is a BOOK! This BOOK lays out these patterns, and that's what we're talking about. The book is called Design Patterns or something like that. But not only the book, there are a lot of sites about them on the Internet and even in Wikipedia, the main thing is that the subject is canonized)) ...and he who does not understand design patterns - plebeian, and who mastered them - he has mastered life itself! Amen!
You're like a clown, alas. Just leave the OOP thread, if it disgusts you so much)
Everything here is clear, specific and canonical. There is a BOOK! This BOOK lays out these patterns, and that's what we're talking about. The book is called Design Patterns or something like that. But not only the book, there are a lot of web-sites about them in the Internet and even in wikipedia, the main thing is that the subject is canonized)).
All of course, if there are up to 100 global variables then we can do without functions, if there are more than 50 EAs then classes are appropriate, and I understand correctly, if there are more than 20 developers and more than 20 methods and number of variables is unknown, then the pattern is needed. If there is only one developer, then if so, not so much?
I'm not stuck, I'm trying out of respect for you as an interlocutor to make sense of your words and unravel your self-contradictions. Apparently for nothing.
I don't think anyone here is interested in your "holy patterns" froth either.
I have no contradictions, the contradiction is in your patterns, I've already written about them twice, let me remind you: a "keeper" pattern promises encapsulation preservation but is implemented by creating two public methods for each private field.
And tell me, where did you see a contradiction in my pattern?
Of course, if there are up to 100 global variables then we can do without functions, if there are more than 50 EAs then classes are appropriate, and I understand correctly, if there are more than 20 developers, more than 20 methods and the number of variables is unknown, then the pattern is needed. If there is only one developer, then, if so, not so much?
Developers need brains in the first place.
You're like a clown, alas. Just leave the OOP thread if you are so disgusted by it)
What "it"? I like OOP. But these notorious patterns have rather distant relation to real OOP.
I don't have a contradiction, the contradiction is in your patterns, I've written about them twice already, reminder: the "keeper" pattern promises to preserve encapsulation, but is implemented by creating two public methods per private field.
I get it now. You just poured emotion against all the patterns, that the meaning of your words was lost.
But in Snapshot this problem is solved by using nested classes for Snapshot.
If it's not supported by the language, I agree, there is this drawback, but it can be bypassed by some crutch tricks I remember.
I get it now. You just watered down the emotion against all the patterns, that the meaning of your words was lost.
But in Snapshot this problem is solved by using nested classes for snapshot.
If it's not supported by the language, I agree, this drawback is present, but it can be bypassed with some crutch tricks, I remember.
You've got it all wrong.
It doesn't matter if it's possible to write a nested class or not, it's not a big difference. There's a code example in this thread with a nested class and two public methods per private field.
What 'it'? I like OOP. But these notorious patterns have a rather distant relation to real OOP.
I'll say it again - nobody prays on the patterns. These are merely patterns which may be used as a reference.
But to state that they have nothing to do with OOP, well, that's not true.
In my humble experience, in pure book form, they are rarely used with rare exceptions. Usually if there is a task suitable for a pattern, it goes together with at least a couple of other tasks for other patterns, and that's how to cross 2-3-10+ patterns, this is a work for the programmer / architect brain.
You don't understand anything.
It doesn't matter if you can write a nested class or not, it's not a big difference. In this thread there is a code example with nested class and two public methods per private field.
You've already told me so many times that I'm a fool and don't understand anything, I'm proud of my composure for not sending you a well-deserved fuck off long ago)
Basically - a nested class makes public methods for private fields optional, that's the encapsulation violation you're writing about. Any other arguments?