OOP vs procedural programming - page 37
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 class has only internal variables and no input or output variables... Where have you seen the use in programming of such an object that has no contact with the outside world and boils in its own juice?
+100
The discussion reminds me of a video the guys showed recently :)
The class has only internal variables and no input and output... Where have you seen the use in programming of such an object, which has no contact with the outside world and cooks in its own juice?
The class has an interface through which it interacts with the outside world. It allows us to cut off all "unnecessary" things that are not intended for external blocks.
For example, in my trade processor I have variables, some of which are intended for MT4, others for MT5 and others for both platforms. But all these variables are absolutely unnecessary to any part of my TS. Respectively, they have no access to them. All parts of the TS receive a virtual interface of the trade processor, in which only functions necessary for the TS operation are defined, and everything irrelevant, all platform-dependent and "trade-specific" are removed.
It's the same with a trade position - parts of TS do not have direct access to a trade position. They can only get a virtual interface that allows counting the number of open trade components, and data of each component. But the TS doesn't even know what it is dealing with - whether it's an MT4 order or an MT5 position. All of this is hidden from her. The TS should not have access to the variables used to deal with MT4 orders or MT5 positions, and it does not.
The class has an interface through which it interacts with the outside world. It allows you to cut off everything "superfluous" that is not intended for external blocks.
Here, in particular, in my trade processor - I have variables, some of which are for MT4, others for MT5, others for both platforms. But all these variables are absolutely unnecessary to any part of my TS. Respectively, they have no access to them. All parts of the TS receive a virtual interface of the trading processor, in which only the functions necessary for the TS operation are defined, and all unnecessary things, all platform-dependent and "trade-specific", are removed.
Let's be very specific and give a very clear example.
1. cotier at the input
2. there is a buy/sell command on the output.
3. Input is converted to output by the intersection of two wipes.
What are the OOPs between them and why?
Explain this to the metaquotes: why did they write huge manuals for the terminal, for the language and in general, where did this mountain of documentation for software products on e.g. Cp... In fact, are there any software products without documentation? It's strange that you don't see that.
Unfortunately, you are mixing up things again. The manual of a program is not documentation. They used to maintain documentation in the last century and obeyed state standards. Now we don't need it all. Now we have only the ToR. The documentation now consists of test cases and class interfaces. Of course, classes are named in such a way that its name alone makes it clear what it does and for what purpose it is used.
Unfortunately, you are once again confusing the terms. A programme manual is not documentation. In the last century, there was documentation, and they followed GOSTs and so on. It is all unnecessary now. All that is left is the ToR. The documentation now consists of test cases and class interfaces. And of course classes are named in such a way that we could understand by their names what they do and for what purpose they are used.
Documentation was kept in the last century, we obeyed state standards and so on. It's all unnecessary now.
I absolutely agree with you here, because they don't write anything serious.
There have always been the ToR. But such simple programs which algorithm can be completely defined in TT were not written in the last century and even now are not written by serious people.
What is it about "test cases and class interfaces" when developing compilers? When programming mathematical algorithms?
PS.
There used to be a rubric for perls.
This is in it.
A program manual is not documentation.
Let's be specific and very clear about an example.
1. the input is a quotient
2. the output is a buy/sell command.
3. Input is converted to output by the intersection of two wipes.
What are the OOPs between them and why?
It's simple enough.
There is an input generator. It requests from the Expert Advisor the interface of the dataprovider, the interface of trade positions and the interface of the trade processor. Then the two interfaces of masks are requested from the dataprovider.
When OnTick() is called - the same function is called from the input generator. The input generator looks at the waving interface, compares its past value. If it detects a crossover, it looks at the trade position interface. If it sees that we are not in position - it calls the trade processor interface for either buy or sell function. If it sees that there is a position, if the position is in the required direction - we do nothing, if it is the opposite - we call the position closing function in the trading interface and buy or sell.
You should note that the generator does not have access to any variables, neither for calculation of wipes, nor for getting a trade position, nor for opening orders in MT4 or positions in MT5. The date-provider only knows about the wipes that have been requested. He recalculates them on every tick and updates them. No one else even knows about it. A trade processor - exclusively fulfills the instructions coming to him through the interface, and does not even know from whom they have come. The Expert Advisor - updates the trade position on every tick and gives it to the requested interface, without studying who needs it and what has inside this block. All blocks are separated and communicate exclusively through predefined interfaces.
Let's be specific and very clear about an example.
1. the input is a quotient
2. the output is a buy/sell command.
3. Input is converted to output by the intersection of two wipes.
What are the OOPs between them and why?
/// применение ООП для элементарных задач (фактически весь код)
OnInit(){
Series FAST_MA=MA(...);
Series SLOW_MA=MA(...);
OnCrossUp(FAST_MA,SLOW_MA,Buy);
OnCrossDn(FAST_MA,SLOW_MA,Sell);
}
But it is OOP in itself within the worked out libraries - it is done to write easily and simply and at the same time to make everything debugged. There are interfaces "the source of quotes" and "the executor of orders", "time series", "indicators" and a lot of other things... But this short code is ready for the rigorous conditions of the real market, with all the glitches and nasties
With an easy move you can take an arbitrary quotient (synthetics) or execute it on another symbol...or just command another Expert Advisor (and this is the advantage of OOP, the complexity inside, and the applied problem requires little effort).
It's simple enough.
There is an input generator. It - requests from the Expert Advisor the interface of data provider, the interface of trade positions and the interface of the trade processor. Then, two interfaces of wipes are requested from the data provider.
When OnTick() is called - the same function is called from the input generator. The input generator looks at the waving interface, compares its past value. If it detects a crossover, it looks at the trade position interface. If it sees that we are not in position - it calls the trade processor interface for either buy or sell function. If it sees that there is a position, if the position is in the required direction - we do nothing, if it is the opposite - we call the position closing function in the trading interface and buy or sell.
You should note that the generator does not have access to any variables, neither for calculation of wipes, nor for getting a trade position, nor for opening orders in MT4 or positions in MT5. The date-provider only knows about the wipes that have been requested. He recalculates them on every tick and updates them. No one else even knows about it. A trade processor - exclusively fulfills the instructions coming to him through the interface, and does not even know from whom they have come. The Expert Advisor - updates the trade position on every tick and gives it to the requested interface, without studying who needs it and what has inside this block. All the blocks are separated and communicate only through predefined interfaces.
Amazing!
I was wondering: is there any other possibility in modern programming to confuse the egg level problem more abruptly?
/// применение ООП для элементарных задач (фактически весь код)
OnInit(){
Series FAST_MA=MA(...);
Series SLOW_MA=MA(...);
OnCrossUp(FAST_MA,SLOW_MA,Buy);
OnCrossDn(FAST_MA,SLOW_MA,Sell);
}
But the OOP itself is inside the developed libraries - it is made to write easily and simply and everything is fine-tuned at that. There's "quote source" and "order executor" interfaces, "timeseries", "indicators" and a lot of other stuff... But this short code is ready for hard real market conditions, with all the glitches and nasties
With an easy move you can take an arbitrary quotient (synthetics) or execute it on another symbol...or just command another Expert Advisor (and this is the advantage of OOP, the complexity inside, and the applied problem requires little effort).
MyOnInit() looks about the same - a dozen lines...
So?