OOP vs procedural programming - page 35
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
Be careful, we're not talking about internal MT variables, we're talking about internal object variables that you've isolated, preventing the possibility of reading their values while debugging and writing code...
That's what I'm saying - when you debug an EA - don't you need MT's internal variables?
Similarly, in this case, with the trade processor object - if you are debugging, say, the methodology of placing orders in your TS - why would you have access to the internal variables of the trade processor ?
Andrei is even more clinical than Peter or Sansanych, you are wasting your time.
Young people need to be taught.
Besides, perhaps there is a rational reason in what my opponents say. If I had, say, such a memory as Peter's, I might not bother with the PLO, too.
It's the same in other places - if some data is required - then this block has to provide the appropriate interface.
That's what I mean... Instead of just seeing the value of the required variable, you have to think about how to attach a suitable interface to it and then unhook it back. :)
It looks like an activity for masochists in programming :)
Yes... you don't get anything better than a dick :) The idea is to have an adequate programming language, to ease debugging and code writing with minimum gestures, but here we have a completely opposite situation...
This is not an 'opposite situation'. It is true that OOP requires some extra work. However, it is more than compensated by convenience of support and system modification.
Here again - coming back to the trade processor - it is written and used in many TSs. It's the isolation of its internals from the TS, and working only through a virtual interface allows not to think about what variables are in it and what they are equal to. If errors are detected, they will be inside the processor and it will be necessary to fix them inside a real class, not affecting the TS classes. If the error is in the TS itself, it will not affect variables of the trade processor.
Encapsulation is actually a very useful technique.
Yes... you can't help but wonder what the heck is in it :) The idea is to have an adequate programming language, to ease debugging and code writing with minimum gestures, but here we have a completely opposite situation...
Debugging is facilitated precisely by the division of responsibility in each class: each class is responsible for its own set of variables. No other class has the right to change their values. As a result, most problems are already eliminated at the compilation stage. And access to variables from any place in the program can be compared to a dozen of steering wheels on one ship.
Young people need to be taught.
In addition, perhaps there is a rational basis in what my opponents say. If I had, for example, such a memory as Peter's, I wouldn't bother with OOP too.
1. How much has the profitability of your advisers increased by using OOPs?
2. How much has your advisors' profitability decreased from the use of OOP?
That's what I mean... Instead of just seeing the value of the required variable, you have to think about how to attach a suitable interface to it and then unhook it back. :)
It looks like an activity for masochists in programming :)
You see, above on the subject, Peter showed you one of his structures, not the biggest one.
Can you easily figure it out?
This very "masochism" is just what allows you, firstly, not to get into the working code and not to spoil it. And secondly it allows you to immediately design the system structure so that you can provide the necessary data in the corresponding blocks of the program.
Yes, indeed, there are situations when you suddenly realize that it is almost impossible to get the needed data. They are hidden behind several virtual interfaces. However, this situation clearly shows that the system was originally designed incorrectly, it did not provide for transmission of this data. This situation is very unpleasant indeed. We either have to hastily build "crutches" in the form of additional interfaces, or restructure the whole system. Well... This motivates the programmer to think more carefully about the system architecture.
If you had less emotion and reflexivity and more specificity in the essence of the discussion - you would not be worth it. :)
There's no substance to this discussion anymore. You are fundamentally flubbing and pretending to be obtuse.
If a moderator shuts down the last couple of pages as irrelevant to the topic of the thread and programming in general - it will be a rare case where I will support his actions.
1. How much has the profitability of your EAs increased by using OOPs?
2. By how much has your Advisors' failure rate decreased from the use of OOP?
1. Not by how much. The profitability does not depend on the OOP.
2. In my opinion, by an order of magnitude (tenfold). But the main gain from OOP is in code support. Now I'm very fast at figuring out the code I wrote a year or more ago. I remember well how I understood my early ANSI C programs in purely procedural style. It was much more difficult.
Debugging is facilitated precisely by the division of responsibility in each class: each class is responsible for its own set of variables. No other class has the right to change their values. As a result, most problems are already eliminated at the compilation stage. And access to variables from anywhere in the program can be compared to a dozen of steering wheels on a ship.
I cannot understand why I have NEVER encountered anything like that in my work. Why the problems of variable access delimitation by ONE developer in one not very large program? There would be 100 developers, each writing 100 functions. Theoretically, it could be invented. But practically programming has evolved to OOP for almost 40 years, mountains of code have been written and never heard anything like it.