OOP vs procedural programming - page 5

New comment
 
Petros Shatakhtsyan:

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 that's why I wrote long and didn't have time to read several pages.

To create a multicurrency engine, you must initially write a multicurrency engine, not redesign a robot that is customized for one pair.

The method to create a multicurrency engine does not require the use of OOP. We can write a block of code taking ticks from all currency pairs and applying the same analysis and order placing functions everywhere. The order functions themselves will contain variables whose values will change depending on the pair. These values will be changed by the block that receives ticks.

 
Реter Konow:
It would be desirable to lead to a concrete task. This description is not very clear. In my practice, the algorithm doesn't change when external parameters change. It is made universal in advance for any values of these parameters. Therefore, it is not quite clear what you mean. Describe it with a specific example.

For example, 100 trailing stop variants need to be crammed into one Expert Advisor. When programming procedurally, you get a mess like this:

if(Trailing_01_ON){
    Trailing1();
}

if(Trailing_02_ON){
    Trailing2();
}
...

...

...

if(Trailing_99_ON){
    Trailing99();
}

100 identical code fragments. When the program is running, only one of the trailing stops will be enabled, and the remaining 99 ifs will just consume resources.

Now for the OOP variant. During Expert Advisor initialization, we scale the array with pointers according to the number of trailing bars, create objects only for the enabled trailing bars. As a result, the following code will work all the time:

for(int i=0;i<cnt;i++){
   p[i].Main();
}

If one trailing stop is enabled, then cnt=1, i.e. there is nothing unnecessary.

 
Dmitry Fedoseev:

The more relevant question here is not "how" but "why"? Why code something that is already implemented in the terminal - just open the required number of charts and attribute an EA to them? In addition, the parameters must be different for different symbols and timeframes.


Nothing has been implemented in the terminal. First, only one chart is opened instead of 20; second, in the tester you will not be able to test many pairs simultaneously, considering all open positions.

Don't tell me that there is "All symbols selected in MarketWatch" mode.

 

A programmer who does not understand how the concept of "Object" is described can be considered an amateur programmer, and does not know the art of modern programming.

 
Dmitry Fedoseev:

For example, 100 trailing stop variants need to be crammed into one Expert Advisor. When programming procedurally, you get a mess like this:

100 identical code fragments. When the program is running, only one of the trailing stops will be enabled, and the remaining 99 ifs will just consume resources.

Now for the OOP variant. During Expert Advisor initialization, we scale the array with pointers according to the number of trails, we create objects only for the included trails. As a result, the following code will work all the time:

If one trailing bar is enabled, then cnt=1, that is, there is nothing unnecessary.

This is a very, very strange approach to solving the task with trailingings in general. There should be no such a task - 100 different types of trailing stops and a different function for each.

You need to compress these types in one or more formulas, making one common trailing stop function. That's all. Of course, you will have to work with gray matter, but OOP has nothing to do with it...

 
Реter Konow:

A very, very strange approach to the trailing stop problem as a whole. There shouldn't be a 100 different types of trailing stops and a different function for each.

These types need to be compressed into one or several formulas, and one common trailing function. That's all. Of course, you will have to work with gray matter, but it has nothing to do with OOP...


Suppose a trailing stop on MA, and there are dozens of them.

And why compress something when you can live easily?
 
Dmitry Fedoseev:

Let's assume trailing MAs, and there are several dozen of them.

And why should something be compressed when you can live with ease?


It turns out that the essence of your argument in favour of OOP is based on facilitating an inherently ridiculous decision. It is a doubtful argument...


Why dozens of different trailing functions? Is it difficult for a serious OOP programmer to write one universal one?

 
Реter Konow:


It turns out that the essence of your argument in favour of OOP is based on facilitating an inherently ridiculous solution. Doubtful argument...

Why is it ridiculous all of a sudden?

Just how ridiculous would it be to use 100 ifs?

 
Dmitry Fedoseev:

Why is it ridiculous all of a sudden?

It would be ridiculous to use 100 iffos.

You don't need to use 100 iffos. You need to solve the problem more efficiently and make one function with trailing adjustments to different parameters.
 
Реter Konow:
You don't need to use 100 ifofs. You need to solve the task more efficiently and make one function with trailing that adapts to different parameters.

And how are you going to make the trailing stop adapt to different parameters? There will still be some branches of the algorithm that with some combinations of parameters will never be executed.

123456789101112...48
New comment