OOP vs procedural programming - page 4
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
George Merts:
Erm... I didn't quite get the point.
The goal was to separate the TC from the terminal. The code must compile on both platforms without any changes. The super task - to transfer all written TS to WealhtLab Developer by writing only classes of working with the trade server.
//--------------------------------------------------
I asked about the current task in order to compare its solutions by several criteria and come to a conclusion about the effectiveness of each. You're taking the conversation away from the practical part. When asserting the effectiveness of OOP, you must be able to prove it in practice. But I'm ready to try and prove my opinion.
So, what is the current problem? I hope you remember it)
If you use pointers to functions, you can do without OOP. But if you don't use pointers, you must understand that you cannot catch up with OOP.
I take it you are not a programmer? Then remember where you were 2017.07.05 14:55 GMT 00, who you were talking to and about what ))
If you use pointers to functions, you can do without OOP. But if you don't use pointers, you must understand that you cannot catch up with OOP.
No. Until there is no concrete task which shows me that I cannot catch up with OOP, I cannot grasp it. Unfortunately. These are just words.
At present I have 4 years of programming practice. You can safely multiply them by 2, because I'm programming a lot of hours every day. During this time, I've solved countless different tasks. I haven't used OOP yet. I can't understand why I need it. In my practice, all tasks are solved without it no less, and sometimes even more efficiently.
No. Until there is no concrete task which shows me that I cannot catch up with OOP, I cannot grasp it at all. Unfortunately. These are just words.
Imagine a hypothetical program that changes its algorithm depending on external parameters, there could be a huge number of variants. It is possible to solve it without OOP, but how dumb those multi-storey switches would look. Moreover, it's clear that performance will slow down as the number of variants increases. It is also clear that building during initialization occurs in OOP and further, during operation, no unnecessary branching occurs, i.e. increasing number of variants will not decrease performance.
A distinctive feature of structured programming is the division of programmes into blocks of code,
which perform a specific task. In this case, the building blocks are functions
and modules (which may be moved to separate files).
More modern is object-oriented programming (OOP).
The concept of OOP refers more to data organization. OOP makes the life of a programmer easier.
The key concepts in OOP are objects and classes.
Classes are structures in which functions are added. And objects are structured variables or instances of classes
Structured programming is the first step. Having mastered it, the programmer gets an advantage. OOP is the next step with the following advantage
Let's solve a particular problem and compare.
Here's a simple task (it would take a lot of writing to explain it in detail).
Everything happens in OnTick(). Suppose, we check some condition and open an order. The condition is not important, let's assume, it is some max or min.
The robot naturally stands on some chart and receives the quotes of this symbol. It is clear that we have not only one function OnTick, but also other functions: OnTrade, OnTimer, custom functions, etc.
Therefore, all the variables that are shared must be declared outside these functions at the beginning of code. For example, such as the symbol name, ask, bid, spread, the number of digits of the quote, etc. There will be dozens of them.
This robot will trade on only one symbol, i.e. where it stands. Let us assume that there are 20 such charts and we will install the same robot on all of them to trade simultaneously for all 20 pairs.
But this is not a multi-currency trading rob ot, as some traders in the Market have pointed out.
Here we need to turn it into a multicurrency robot. I.e. we put it on any chart (only on 1 chart) and it opens deals for 20 pairs. It means we launch it in the tester in solitary mode and it will trade on those pairs that are in Market Watch.
Here is how you will implement it without OOP. Will you transform all common variables into arrays of 20 elements?
And what about the functions that will be called simultaneously for all pairs?
You can't do without OOP. :)
P.S. I want to note, that I have not Russian education, and consequently long wrote, and did not have time to read several pages.
If you use pointers to functions, you can do without OOP. If you don't use pointers, you must realise yourself that you can't catch up with OOP.
I disagree. I used to write digital TV programs at one time, the compiler was C++, but it was used within C because memory was scarce. Pointers to functions were used very extensively, but this is nowhere near OOP.
...
Here's how you're going to do it without OOP.
...
The question that is more relevant here is not "how" but "why"? Why would you need to code something that is already implemented in the terminal - you just need to open the required number of charts and attach them to the EA. In addition, for different symbols and timeframes the parameters are likely to be different.
I disagree. I used to write programs for digital TV, the compiler was C++, but it was used in C because memory was scarce. Pointers to functions were used very extensively, but it is nowhere near OOP.
It is not very convenient but you can do with pointers alone as far as performance is concerned.
And convenience is a relative concept.
Imagine a hypothetical program that changes its algorithm depending on external parameters, there could be a huge number of variants. We can solve it without OOP, but how dumb those multi-storey switches would look. Moreover, it's clear that performance will slow down as the number of variants increases. It's also clear that with OOP there is a build at initialization and then no unnecessary branching during the work; i.e. increasing number of variants won't decrease performance.