Structure rules. Learning how to structure programmes, exploring possibilities, errors, solutions, etc. - page 10
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
I am no stranger to State programming and used it myself for several years. However, after some time of using this method I decided to abandon it and developed a more transparent, simpler and more suitable model for trading on its basis.
Read carefully this article: Auto programming as a new way to create automated trading systems
Then read carefully these comments on it.
Then very, very soulfully contemplate one unsightly plaque from the article, and think what it could mean:
If, after reading all this, you're still going, "Wow! State programming is so cool!" - well, count on it.
I would add that the main problem of State programming is situations which produce a lot of useless modes (see column N State). In State programming, each mode should describe its own rules separately. Let's explain by example, let's say we are in Buy mode. Everything is fine until the robot decides to open one more position. And why not? The conditions of exiting the old position have not been met and it is too early to close it, while a new signal should not be missed. And here is where the problems begin, because at the moment of a new signal arrival the robot is in Buy mode, while rules for opening a new position are in State mode (waiting for and searching for new entry signals). Now in Buy mode we have to re-describe the same position opening rules that are used in State mode. And if a new position is opposite in direction (hedge)? This position is opened, but what to do with it? After all, its management logic is described in the Sell mode, while the robot is in the Buy mode. We can simply switch to Sell mode but what to do with the remaining Buy position? In general, in this case we have to write one more useless mode like BuyAndSell. Redundancy of modes produces one more situation: one and the same action is performed by different code sections. All in all, for those who like exponential programming mess, this is the best.
"That's how it is Mihalych" (c)... That's what I'm hinting at, too.
(fcplm)
No way.
I was just thinking that if MQL5 supported multiple inheritance and a class could declare abstract methods, it would open a way to use interfaces, which would be great for large projects.
Abstract methods are not explicitly forbidden (I often use alternative notation),
And the multiple inheritance would be a huge plus.
Abstract methods are not explicitly prohibited.
To quote Rosh: how does this help you sawing firewood?
Von's FAQ is sitting on quadruplet and doesn't give a damn about abstract methods and multiple inheritance.
It doesn't matter if there will be abstract methods or not, anyway, the task of project structuring will not be solved.
By the way, the more implementation variants of one and the more difficult it is to choose which variant to use.
So it turns out that the programmer often gets stuck in the task of code beauty. It is an art for the sake of art.
I've noticed, generally (speaking for myself), that the more stamps of project planning, the easier it is.
Then you may change, modify, re-modify, over-modify,
But the initial framework (even if it's not great) sets the tone for the whole build.
To quote Rosh: How does this help you to saw firewood?
Then you can change it, modify it, re-modify it, over-modify it,
but the initial framework (even if it's not great) sets the tone for the whole build.
The speed of sawing firewood will increase.
If you already have a clear idea of how and what should look like - you can probably do everything smartly in MQL4.
And if there is no such a notion - it means that there will be a lot of changes and additions. And the multiple inheritance allows for changes with minimal costs.
I agree with the abstract methods - it's just a nice form of recording.
The speed of firewood sawing will increase.
If you already have a clear idea of how and what should look like - you can probably do everything smartly in MQL4.
And if you don't have such an idea - it means a lot of changes and additions. And the multiple inheritance in particular allows making changes with minimal costs.
Nowadays, inheritance is tried to be abandoned in favour of inclusion. Can you imagine the attitude towards multiple inheritance?
FAQ:
No way.
It's not. Using a switch... case and using a state machine pattern are two different things. You can tell from the text that there's no such thing as a pattern, just like in the article you cited.
It reads something like "I've invented a unique winning system..." and then a crooked martin statement.