My approach. The core is the engine. - page 138
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
"Expanding the creative potential of OOP supporters", Vereshchagin, Canvas, Oil
Thank you all for the informative posts.
Today we will test the communication between the EA and the engine via resources. Just completed it. Should work in the tester as well.
You are working with the CCanvas class. It is the only one in your development.
The class is part of the system. If it is ONE, there is no system.
Then why create class objects and refer to its functions by OOP rules?
You PRACTICALLY don't need OOP in dealing with ONE class.
But, you do use OOP in dealing with ONE class. You don't need OOP, though.
Peter, in OOP, class objects are created so that you can work with multiple objects that don't depend on each other. When you work with CCanvas and you have one graph everything is fine, OOP is really not needed here. But when you need to display several plots in different areas, it's hard to do without OOP and creating multiple instances of CCanvas.
Or one more example. Recently I've been asked to modify a procedural Expert Advisor so that it could trade on different symbols simultaneously (running on one chart). Procedural style would have required long and complex efforts to make it trade independently on different symbols at the same time. In contrast, I simply placed the entire procedural code in a class and created three exemplars. I specified an individual set of settings for each of them, including the work symbol, etc. The code worked properly on the first try. The code worked as it should have done on the first try. The user was satisfied.
Even you are using OOP in your kernel. Although you do it implicitly:
In order not to be unsubstantiated, let me finally give you an example of that very "kernel". More precisely, it is a boot file. There are several cores in it.
Let me remind you that it is printed automatically, based on KIB-code. Then placed in the engine. Next, the engine works with it.
Each your kernel is an instance of a class in OOP terms. However you may call it, but it is an element of OOP. But unfortunately, this element is self-made and inferior in conceptual power to what has already been invented and polished by thousands of untrained minds.
Why are you people trying to convince Peter of the benefits of OOP?
You won't convince him! If you had a memory like his, you would wonder why all this OOP stuff is so complicated when you can do everything so much simpler? We make all variables global, direct access from everywhere, no bans and restrictions - nice!
That's for those who in their feeble mind may forget what they wrote ten years ago - it is necessary that the compiler and the language limits it in every way. And when you remember exactly why and why you wrote this or that construct in your code, which is many years old - OOP is only the fifth wheel in the cart.
Peter's problem is not in the choice "OOP or procedural approach", Peter's problem is in the target audience. The lack of people who, on the one hand, are good at programming and, on the other hand, prefer to trade hands. I do not observe such people.
1. Exactly. A limited number of elements can be prescribed in the constructor. Hence, a dynamic table must consist of a limited number of rows, but at the same time, be unrestricted. The solution only lies in creating special arrays for added parameters and scrolling their values through the table cells.
2. Yes. Constructor creates kernel for engine based on the code you cited. + prints the connection files. Then, I put the kernel into the engine (DRIVE). After that, the engine can play the desired GUI. Pairing files are connected to the EA and start interacting with it.
It turns out that every time for a new gui you have to make changes in the engine (provide it with the appropriate GUI kernel). I think this is a fundamentally wrong solution. Imagine that there are hundreds of users of your engine. But the engine hosted in the Market or elsewhere is only one. How will you do in this case? For each user to place a specific engine, which he must download for himself? How do you prepare the gui core for the engine? Will you provide each user with an individual engine? - This will quickly become a nightmare. So your solution is not scalable.
Peter, in OOP, class objects are created so that you can work with multiple objects that don't depend on each other. When you work with CCanvas and you have one graph everything is fine, you really don't need OOP here. But when you need to display several plots in different areas, it's hard to do without OOP and creating multiple instances of CCanvas.
Or one more example. Recently I've been asked to modify a procedural Expert Advisor so that it could trade on different symbols simultaneously (running on one chart). Procedural style would have required long and complex efforts to make it trade independently on different symbols at the same time. In contrast, I simply placed the entire procedural code in a class and created three exemplars. I specified an individual set of settings for each of them, including the work symbol, etc. The code worked properly on the first try. The code worked as it should have done on the first try. The user was satisfied.
Even you are using OOP in your kernel. Though you do it implicitly:
Each of your kernels is an instance of a class in OOP terms. And whatever you call it, it is an element of OOP. But unfortunately, this element is self-made and yields in its conceptual power to what has already been invented and polished by thousands of untried minds.
Vasily, I understand why the drawing functions are made into a class. Because there are other sets of functions besides them.
But my question was a bit different. Why, exactly, would Nikolai use calling the drawing functions through a class, if he didn't use any other classes. He only draws.
The point of the question was exactly that.
I stressed the pointlessness of this action in terms of logic, and that he is not aware of it.
I also stressed that use of OOP is often unreasonable by the size of tasks to be solved. After all, OOP requires a branching classification, and if there is no such a classification, is it worth creating it on purpose?
The point is that the developer should be guided by the requirements of mechanisms, not tools.
Peter, in OOP, class objects are created so that you can work with multiple objects that don't depend on each other. When you work with CCanvas and you have one graph everything is fine, you really don't need OOP here. But when you need to display several plots in different areas, it is hard to do without OOP and creating multiple instances of CCanvas.
Or one more example. Recently I've been asked to modify a procedural Expert Advisor so that it could trade on different symbols simultaneously (running on one chart). Procedural style would have required long and complex efforts to make it trade independently on different symbols at the same time. In contrast, I simply placed the entire procedural code in a class and created three exemplars. I specified an individual set of settings for each of them, including the work symbol, etc. The code worked properly on the first try. The code worked as it should have done on the first try. The user was satisfied.
Even you are using OOP in your kernel. Though you do it implicitly:
Each of your kernels is an instance of a class in OOP terms. And whatever you call it, it is an element of OOP. But unfortunately, this element is self-made and yields in its conceptual power to what has already been invented and polished by thousands of incompetent minds.
You are wasting your time. Firstly, your example with advisor to Perth is a poultice - he can't write experts, he doesn't understand what's there and what's the point, and he can't understand your very clear example - you'll see, he, batting his eyes, will tell you the same thing as he told Nikolay. Secondly, you will give him an excuse to push his nose even higher, saying that he has made a super-unique code in his bucket by himself, without the help of thousands of previous minds, with an outstanding solution better than any previous solution. You'll see - that's exactly how he will position his unique bucket with sliders...
ZS. I may have spoken harshly, but I have very little tolerance for impenetrable stupidity.
Each of your kernels is an instance of a class in OOP terms. And no matter how you call it, it is an element of OOP. But unfortunately, this element is self-made and yields in its conceptual power to what has already been invented and polished by thousands of incompetent minds.
So it is. But still, there is a significant difference. As far as I am concerned, at Peter's - in this exemplar of class - almost everything is available. And this does not fit into the encapsulation paradigm of OOP. Plus, there are global variables.
So here - only "elements of OOP".
But, I'm afraid, people won't like the converse - I'm sure, Vasily, that when I roll out my OOP-project, on the contrary, people will scream that "you can do nothing with this interface, except what it is intended for" :)
It turns out that every time you make a new gui, you have to make changes to the engine (equip it with the appropriate GUI kernel). I think this is a fundamentally wrong solution. Imagine that there are hundreds of users of your engine. But the engine hosted in the Market or elsewhere is only one. How will you do in this case? For each user to place a specific engine, which he must download for himself? How do you prepare the gui core for the engine? Will you provide each user with an individual engine? - This will quickly become a nightmare. So your solution is not scalable.
No, Vasily, you tend to dramatize everything.)
There is a button in the designer, which, when clicked, prints all the files.
And the engine will load kernels from a text file. It's not hard to do.
Peter, you really misunderstood something about the application of OOP.
It's a special form of consciousness, don't stop it from evolving