Structure rules. Learning how to structure programmes, exploring possibilities, errors, solutions, etc. - page 3
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
Come on, I didn't have any model at all, then I started with procedure, then switched to object model.
And in general, by default MQ gives us an event-based model. We are initially given the events by which everything happens.
Are we talking about mq5?
so we're talking about the same thing.
From the branchcalled "Errors, Bugs, Questions":
A very typical problem for the beginning of design: how to organise (structure) event handling in a program so that it (the program) can be further developed and at the same time minimal reworking of what has already been done.
Do you want to discuss options?
In general, this is a more global issue and is not just about organising a good event model. Much depends on the language itself. Unfortunately, the linguistic means of MQL5 are on the level of the 80's of the last century. Modern programming standards are far away from the original OOP programming principles. Today decomposition is preferable to inheritance, polymorphism is ensured by horizontal non-hierarchical links at interface level, and code reuse is ensured by rich collections of standard libraries, decomposed design and transparent inclusion of third-party builds into the project.
Is there any literature for example?
Specifically on this topic:
Which language do you consider as a role model (in terms of modernity and usability)?
Java/C#
And it's not even about my bias (although I'm not without it), but because these languages are the end product of a long evolution in programming technology. They were created in our time, and were based on the experience of their predecessors.
Before writing a large project, it is a good idea to establish a clear established infrastructure to support the project:
Is there any literature for example?
Of course there is.
// About literature: let's share literary sources. But let's not forget that live communication is sometimes much (orders of magnitude) more effective for learning than books (even good ones).
--
The book was very helpful at one time (early 90s):
B.Liskov, J.Gatag. "Using abstractions and specifications in software development."
From it, I learned well the main point of object-oriented programming, which is not the additional possibility to cut the program into convenient "cubes" - this is only an additional accompanying convenience. The main point is data abstraction.
you think in object-oriented way, I think in functional way )
1. procedural (algorithmic) abstraction is a feature of functional programming. The abstracting entity is procedure (function). It allows to separate a request to perform an action or calculation from its implementation. The function code is isolated into a separate block (procedure, function), this code is referred to via decoupling of formal/actual parameters (this is the essence and main feature of the procedural approach). The program is able to remain unchanged when it is necessary to change the way (algorithm) of calculation or action (e.g. writing to a file).
But if a program needs to change any basic data structure (global arrays for example), it's going to need to rewrite lots of procedures working with this data. -- This is a basic limitation of the procedural programming style.
2) Data abstraction - encapsulation of basic data structures (together with basic operations on them) into separate entities ("classes"), in compliance with the basic rule: never refer to them (encapsulated data) directly, but only and exclusively through the functions of the same class, specifically created for them ("interface"). Thus, the abstraction of data storage form from the ways of handling this data is achieved.And there is an unprecedented opportunity (in procedural programming) - to develop a program without worrying in advance about the ways of data representation. Since the data are accessed through a standard unchanging interface, you can improve the ways of data representation at any stage of project development, and this change does not entail the need to change other parts of the project. In procedural programming this was impossible - the basic data structure strictly determined the ways of their processing.
I was also taught to sketch on paper, a simplified algo language, before writing the programme, but I never got used to it.
Nowadays, no normal programmer draws flowcharts. It is all theoretical nonsense designed for teaching schoolchildren, but not for working in real projects.
I draw on paper, it's more convenient for me, sometimes it takes up to 50 sheets until a clear structure emerges. You can, of course, use special editors, but each of them for me is uncomfortable (limited), impossible to realize a flight of fancy, in short they slow down the work.
And what will happen to your clear structure if in the middle, or even closer to the end of the project, the customer will suddenly change:
This is a good test to see how ready and resilient your project is to change. In practice, you always have to deal with changes in the initial requirements. It is therefore better to move away from the 'Provide for everything' paradigm altogether to the 'Task - Solution' paradigm.