Questions on OOP in MQL5 - page 54
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
https://www.mql5.com/ru/forum/85652/page52#comment_16423899 Why the surprise?
not surprise but disbelief. your level of mastery of the subject is perfectly evident from the posts in this thread.
Are you an expert on levels? ...urban communications.
yeah, go on, tell me, titles read doesn't mean studied, you're like STL with patterns which is "stl is a vector"
You came in here and broke up a big-headed man's heart-to-heart.
You were sorry? The man was dreaming, you played along.
))))
What did you feel sorry for?
Dmitry Fedoseev,
Why are you getting so upset, my dear?)
Well, you do not like the patterns, well, do not use them. Or you don't like their names, use them, but don't call them "patterns". Do as you like, as long as it suits you.
But to deny their meaning is empty. As well as to exaggerate it ;)
You confuse algorithms for solving programming problems with the so-called, and now fashionable, "design patterns" related exclusively to OOP. And you confuse a lot of other things, and read inattentively. A little earlier I wrote - use the structure. But if you had read that post and I hadn't mentioned the function of copying the entire class, you would have got to the point that we are adults, so why bother with unnecessary structures when we should do everything maturely - just provide the ability to copy the entire class.
1. This thread is about OOP, so I am not confused.
2. Does the structure change the essence of the Snapshot pattern in any way?
3. there's no extra work to be done. It's just a question of weighing what will be more - "extra" work now, or later when expanding and developing the project.
4. What is this about? It's not necessary in the snapshot.
1. The thread is about OOP, so I'm not confused.
2. Does the structure change the essence of the Snapshot pattern in any way?
3. there's no need to do extra work. It's just a question of weighing what will be more - "extra" work now, or later when expanding and developing the project.
4. What's this about? It's not necessary in a snapshot.
You're stuck in the minutiae. It's not interesting. 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 get the most important message.
But may I ask, what is a pattern in the local sense of the word? I'm kind of lost, really. Is it a wrapper for some tasks or a state of a task? With classes, structures, pointers and dynamics, I think I understand them better. It's also clear that the terms haven't quite caught on and been defined yet. And are there any conditions that can be used to determine when they should be applied. In the case of photoshop and rendering it is clear, but these are not time series tasks. Or maybe I'm missing something and there's something in common in visual rendering and GA VR?
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!
I don't claim to have an opinion, I may have read it somewhere, but imho, there are only two problems in programming: the correct programme structure and quickly finding a good name for a variable, and the rest 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)))
Exactly - the right structure. That's why you should consider all possible options of this very structure, analyze their pros and cons in a given task (taking into account scalability requirements and maintenance etc) and choose the best one.
And the notorious patterns themselves (whatever exactly they are meant to be) are not even a variant of the structure here but just a reference point for the brain. It's like "If the problem fits the description of pattern X task, then it can be solved by applying pattern X", but you can solve it in a heap of other ways as well.
And in general, those 27 base patterns were born as a kind of hint for programmers on typical problems how to solve them following the OOP principles. If there is no task to follow the principles, as Dmitry has with structures, then you don't need any patterns.