
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
A "design pattern" is simply an agreement to call the same frequently occurring things by the same names. And by the way, the term comes from architecture (where sculptures/bridges/portals/portals are concerned).
Sometimes similar things are solved with similar techniques, not always... But it's useful to agree on the similarity of things and methods in order to understand each other.
but of course there are the "give a fool a glass phallus and he'll break the thing and cut himself" people.
Yeah, assigning a value to a variable is now called a Keeper or Snapshot (depending on the number of variables:), and putting part of code into a function and returning the value by reference is now called a Factory, etc.
These patterns have nothing to do with real use of OOP and nothing to do with real patterns that are used in OOP.
what is meant by "studied"?
if you have read the description on several forums, there are a dozen of them
If applied in MQL, then one - strategy.
Studied - not only read, but also understood, and wrote a training example for myself.
And this "strategy" pattern, how did you apply it? Have you read about it somewhere, studied it and then applied it? Or did you write and write something, and then look at it and, lo and behold, it turns out that I applied the "strategy" pattern?
Yep, assigning a value to a variable is now called a Keeper or Snapshot (depending on the number of variables:), and returning a value by reference is now called a Fabricoyne, etc.
These patterns have nothing to do with the actual use of OOP and no real patterns that apply in OOP.
well, you've had a lot of bad cognac somewhere...
Nothing is embedded in them. How many patterns have you studied?
It's not about learning. You don't have to know every line of the 31st volume of the BSE. But you can open the right one and find out what's of interest. And use it where it is needed.
One can use someone else's previously accumulated knowledge (not one-to-one lines of code, but the optimum logic previously voiced by someone else). You can go your own long way, inventing your own bikes. And you can read a smart book and not be able to make a step without strictly following the postulates it contains. But that's about the adepts, and let them.
Studied - not just read it, but understood it and wrote a case study for myself.
Or wrote something, wrote it, and then looked at it, and oh miracle - it turns out I applied the "strategy" pattern?
Exactly the opposite, first there was a miracle - my code structure, then I studied the pattern and completely rewrote the miracle from scratch according to the pattern - got the convenience of further use
It's not about learning. It is not necessary to know every line of the 31st volume of the BSE. But it is possible to open the right one and find out what is of interest. And use it where it's needed.
One can use someone else's previously accumulated knowledge (not one-to-one lines of code, but the optimum logic previously voiced by someone else). You can go your own long way, inventing your own bikes. And you can read a smart book and not be able to make a step without strictly following the postulates it contains. But that's about the adepts, and let them.
The analogy of these patterns with the encyclopaedia is totally inappropriate and not realistic. For these patterns, the well-known analogy of the empty barn and the inscription is more appropriate.
Well, you've had some bad cognac somewhere...
Yes, right in this thread a few pages ago.
How many patterns did you study?
Exactly the opposite, first it was a miracle - my code structure, then I studied the pattern and completely rewrote the miracle from scratch according to the pattern - got the convenience of further use
I had 20 or 30 pieces, and when I had finished I laughed. Then I searched the Internet and found another 20 or so ideas, but I didn't study them, just laughed.
how many patterns did you study?
Exactly to the contrary, first there was a miracle - my code structure, then I studied the pattern and completely rewrote the miracle from scratch according to the pattern - got the convenience of further use
there is always a counter-thesis: was it necessary to improve the resulting miracle?
programming-for-programming sake, you got the same eggs but in full view
there is always a counter-thesis: was it necessary to improve the resulting miracle?
programming-for-programming-soon-to-be-programmed got the same eggs but in full-face.
yes it was worth it
there is a stable opinion that OOP is a wrapper over procedural programming what 99% of forum participants are engaged in
and there is a 1% opinion that OOP allows you to build the further code structure at the design stage, I'm still checking this truth
and write in full-face and profile.... well kinda passed, not interested in opting MACD Sample ))))
I did 20 or 30 of them, when I finished - I had a laugh. Then I searched the Internet and found 20 more samples but I failed to study them and just had a laugh.
20-30 is a lot of work, imho, I can't even think of that many problems.
although it's possible you've used 20-30 patterns, like... like the names of samurai swords? - one for fish and another for harakiri, and you use the same sword to peel fish and slice up sausage for dinner? - not by sensei!
)))