OOP vs procedural programming - page 14
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
Can you give me an example of these single-type tasks, which are better not to do without OOP?
Without OOP you can solve it, but with OOP it's faster, I told you...
For example, a pattern may contain from 0 to 100 candlestick patterns, from 0 to 30 different indicators and from 1 to 5 different signals in each of them... So, we have 1 class, and we can set with the constructor that the first instance will contain 23 such patterns and 2 indicators with 1 signal each... The second instance will contain 12 other patterns and 8 other indicators... Then we set the condition that both instances must give a signal to open not more than 4 bars away from each other ...
All this stuff is done in 5 seconds if the patterns signals and everything else is described in the class... And there can be as many combinations of all this as you want, and even without a customer, just optimize all this automatically in the optimizer and look for favorable entering conditions... The optimizer can enlarge the number of instances and properties of each of them... well, etc. ))
This is not the main argument.
There is no analog of polymorphism in procedural programming.
It is strange that during all my practice, since I was a complete novice in programming and still am to some extent, I never found it necessary to use polymorphism... That must be my fate.
(Hell knows why...))
Without OOP you can solve it, but with OOP it's faster, I told you...
For example, a pattern may contain from 0 to 100 candlestick patterns, from 0 to 30 different indicators and from 1 to 5 different signals in each of them... So, we have 1 class, and we can set with the constructor that the first instance will contain 23 such patterns and 2 indicators with 1 signal each... The second instance will contain 12 other patterns and 8 other indicators... Then we set the condition that both instances must give a signal to open not more than 4 bars away from each other ...
All this stuff is done in 5 seconds if the patterns signals and everything else is described in the class... And there can be as many combinations of all this as you want, and even without a customer, just optimize all this automatically in the optimizer and look for favorable entering conditions... The optimizer can enlarge the number of instances and properties of each of them... etc. ))
This whole GOP debacle is on a universal scale.
After all, you have to have so much talent to push something like this around the world.
And nothing stops the apologists.
If you take local apologists. Right under their noses is the handbook of MQL language. Let's look at the sections. Only three sections are devoted to data and all the rest describe the ACTIONS: program, array operations, data conversions.....
Could it be that this is an μl language that doesn't conform to "cutting edge ideas"?
Take a much larger software system: R.
It contains over 10,000 packages, each containing functions - these are actions, not objects.
As I see it, all these apologists of OOP of local and world origin understand nothing in programming, namely: the value (semantics) of any data is a function, an action which processes this data. They wrote int. The meaning of these characters is determined by a set of processor commands, which knows how to perform ACTION with this variable.
Next, let's move on to classes.
If we take R, for which classes are part of the language.
A function inputs an object of some class - the output is an object of usually another class. The meaning of input-output fields is determined solely by the function that handles it all. And if the function does not accept a certain class, this class is of no use to this function. That's why the documentation for each package is exactly the same as the one for µl: actions and functions are listed. And links between functions in one package, or with functions in another package, are determined by the name of the class that the particular function works with.
Again. In R, objects can have arbitrary complexity and can actually be very complex. But the value of each field of an object of a certain class is entirely determined by the function that generates that object.
This is especially obvious for those who wrote compilers (and I did). Some sequence of code is written. What does this code do? What is the meaning of this code? The meaning of the text in the source language of any programming language will be determined by the executable code that the compiler creates, which will eventually be perceived by the processor. One language compiler will find the meaning for the written lines, but another will not, i.e. the written lines have no meaning for this other language.
Hence: the meaning of an object is always a function, an action which is able to take input data as a guide for action, and generate in the output a certain list of fields, the value being determined solely by this function.
Konov tried to explain above that we have to go from ACTIONS. It is necessary to deal with actions, and objects connecting these actions are to be dealt with later, when the actions are defined. But code's clarity and efficiency comes purely from how well we've managed to organize the whole hierarchy of ACTIONS and their interaction.
Proponents of OOP say: let's create objects. But what is the meaning of object fields if we don't define actions on these fields?
How is the pattern that contains patterns implemented? Is it a function or an array or something else? How are the patterns themselves written?
yes they are usually described, that's not the point...
Another example... a class is like a library with books, and a copy is a trolley... On a trolley you can put books of your choice from the library... ... and look for something more profitable...) Library and 1 trolley can be done without OOP, and when we are talking about a large number of trolleys, it's better to do it with OOP...
This is the only argument in favour of OOP in development that I now accept.
You shouldn't accept it.
The last team I worked on had about 300 people. The total workload for the whole programme project is around 1500 man-years. Organising such a team to work together will not help any OOP. For this, there were other approaches, involving the breakdown of the whole problem into stages and the careful regulation of everything and everyone at each step. There were GOSTs that described it. In programming, it was the USSD (Unified System of Program Documentation). In terms of labor intensity, coding itself took about 20% of labor input.
Don't listen to the advocates of OOP. You are on the right track. Even the fact that you don't merge two variables into one structure - you can't see the profit from such a merging
Another simplest example, which is on the very surface... EA generator in MetaEditor... Anyone, even if he doesn't know how to program can cobble together an EA containing a huge number of indicators and conditions in 10 seconds )))) And all this is OOP )))
Let's not talk about the generator, because I've decided not to swear for 2 months )))
Comrades MQ developers, I have a lot of respect for you. I mean it.
And I understand the reasons for creating these constructors. I also understand why it is that all these constructors are farting in a vacuum.
Yes, it can be seen as a kind of example to study MQL5, but by no means as a starting point for a real trading robot.
You shouldn't accept it.
The last team I worked on had about 300 people. The total workload for the whole programme project is around 1500 man-years. Organising such a team to work together will not help any OOP. For this, there were other approaches, involving the breakdown of the whole problem into stages and the careful regulation of everything and everyone at each step. There were GOSTs that described it. In programming, it was the USSD (Unified System of Program Documentation). In terms of labor input, coding itself took about 20% of labor input.
Don't listen to the advocates of OOP. You are on the right track. Even the fact that you don't merge two variables into one structure doesn't make much profit
San-Sanych, I was recently contacted by a so-called progager who even managed to sell something in the Market.
He said I tried to glue some programs and got a compilation error, so to say, he sent me his glue. He promised to pay me.
I took a look and I'm sick, 59 compilation errors.
Lots of global variables like n,c,m.
All conflicting with each other.
And the guy's sure he just needs a few tweaks and he can throw it in the Market.
...
According to my understanding, all these apologists of OOP of local and worldwide origin understand nothing in programming, namely: the value (semantics) of any data is a function, an action, which processes this data. They wrote int. The meaning of these characters is determined by a set of processor commands, which knows how to perform ACTION on this variable.
...
in memory
You shouldn't accept it.
The last team I worked on had about 300 people. The total workload for the whole programme project is around 1500 man-years. Organising such a team to work smoothly is not going to help any OOP. For this, there were other approaches, involving the breakdown of the whole problem into stages and the careful regulation of everything and everyone at each step. There were GOSTs that described it. In programming, it was the USSD (Unified System of Program Documentation). In terms of labor input, coding itself took about 20% of labor input.
Don't listen to the advocates of OOP. You are on the right track. Even the fact that you don't merge two variables into one structure doesn't show any profit
Such programs are now written by one person in three days.