Overhead for the PLO - 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
1. For example, you need an array of objects.
You can do it procedurally, or you can do it based on CArrayObj and CObjest. The problems start when you need to change the behaviour of, say, adding or removing objects, or sorting them. In OOP, support for a pointer array proper and working with it is enclosed in the base objects. Modifying descendant objects that are actually contained in the array does not affect anything. In procedural style - modifying real objects that are actually contained in an array - usually affects a lot more places, at least because we have to consider changes in the size of objects. Which will much more easily lead to errors.
2. Cross-platform - also much more convenient to organize in OOP-style. When on the request, say, a trade position - we get an interface, and it does not matter what platform we work on - the interface offers virtual functions, on which you can get all of the data on all orders (for MT4) or positions (MT5), and, from the expert point of view - there is no difference. The Expert Advisor does not need to know what platform he/she works on.
3. Well, "finishing in procedural programming" is "writing objects-procedures", that is, the creation of some links between data and procedures, which represent objects in OOP.
4. And then we have, say, a number of kinds of orders, which have a lot in common. It would be reasonable to make an object COrderInfo - which would be the base object, and its heirs would represent different kinds of orders. At that, the trade processor (I have the CTradeProcessor class) will automatically support precisely that order, which has been passed to it, by those procedures that are required for processing that order.
5.It is easier to catch bugs where there is the least amount of cross-links. This is ensured by encapsulation and polymorphism. We request the trade position interface (CTradePositionI) and all connections with real classes, representing this position (CMT4PositionInfo,CMT5PositionInfo) are made only through this interface, that just contributes to easier error correction, than if we work directly with real functions, returning trade position data.
1. What for?
Why cannot the same function be compiled on different platforms?
3. the idea was to pack the text of functions by the structure type to make it more convenient to refer to them by analogy with referring to a function as a class member. No object needs to be created for this purpose in principle.
4. It would be more reasonable to make a single function with its settings, instead of multiplying several objects and unnecessary connections through interfaces.
5. In addition, all these links should be programmed and then tracked through the interfaces and the like, where bugs may be difficult to catch. This occupation is unnecessary and senseless from the very beginning.
1. For example, what for?
2. Why can't the same function be compiled on different platforms, so that you don't have to create interfaces for it?
I meant packing the text of functions by the type of structure for more convenient access similar to addressing a function as a class member. In principle, no object shall be created for this purpose.
4. It is smarter to make a single function with settings, instead of multiplying several objects and unnecessary connections through interfaces.
5. In addition, all these links should be programmed and then tracked through the interfaces and the like, where bugs may be difficult to catch. This occupation is unnecessary and senseless from the very beginning.
1. Well, CTradePosition class is essentially a list of open orders. And for them, it would be very useful to have an interface, a base class, and actual classes.
2. There is only one interface. For all the platforms. And in the case of OOP, we do not really think about where we are working. We do not have to consider platform-dependent and order-dependent things.
And what is the difference between object and function in this packaging? That's what I'm saying - it's essentially the same thing. In the case of an object - an automatic constructor function is also added, however, by default - it is empty.
4. Exactly, this very "single function with settings" is the source of the problems. Because there are usually a lot of settings. And they are not scattered at different levels of class hierarchy, but concentrated in this very function. But the interface allows you to leave all the settings not used in a given context "out of consideration" - which has a very good effect on the understanding of the code and possibilities of errors and their detection. This is exactly the main advantage of OOP - all the functionality is "scattered" in objects at different hierarchy levels and when working with this or that part of it - others do not interfere. In a single function with settings, on the other hand, all the functionality is always available, even if it's superfluous. This is usually a source of problems simply because you can accidentally mix up the variables. The main disadvantage is that it is much more difficult to detect errors in such a single function.
5. in any case, these links are needed and they must be programmed - they are, in fact, the same settings in a single function. For example, in my example - in a single function we have access to the difference of platforms, different order types, difference in position representation - all this has to be taken into account. And when there is an interface - everything is "cut off" - only what is defined in the interface can be taken into account.
That's the point of encapsulation, to limit access from one block of code to another block. On the contrary you suggest to have "one big universal function with maximum settings", so that anyone who has access to this function has maximum possibilities. This, as my experience shows, is the wrong way. The right way is on the contrary, to limit the user as much as possible, if one block of the program needs the functionality of another block - it should have only this functionality, and not one bit more. This is the key to a more stable and error-free code.
1. Well, CTradePosition class is essentially a list of open orders. Orders can be different, and for them it is very convenient to have an interface, a base class, and real classes.
And what's wrong with keeping the orders in an array of structures, or in the way that it is implemented in MT4?
What's wrong with keeping orders in an array of structures or as implemented in MT4?
Because each user has too many rights and too much unnecessary information when accessing this array.
The right thing to do, in my opinion, is to give the user only the part of the functionality they need - just by using a pre-agreed interface to access orders.
That each user has too many rights and too much unnecessary information when accessing this array.
The right thing to do, in my opinion, is to give the user only the part of the functionality they need - just by using a pre-agreed interface to access the orders.
You can create your own data type for orders, there's no need for any interface, objects and other unnecessary contrivances, which create unnecessary bugs and instabilities.
You can create your own data type for orders, there is no need for any interface, objects and other unnecessary contrivances, which create unnecessary bugs and instabilities.
My experience shows that you do need to.
I went this way about five years ago, back then on MT4. (Not because I didn't know about OOP, but because I was too lazy to bother with interfaces and inheritance, especially since at that time MT4 and MT5 were significantly different in terms of MQL implementation). This led me to the understanding of its fallacy. This is not "wisdom", but quite a reasonable limitation, a kind of "foolproof". If you always remember what each of hundreds of variables is responsible for - you don't need encapsulation. I don't remember this, and I prefer to have as few entities available in each block of a program as possible.
As soon as MT4 appeared OOP - I immediately started to translate all my developments into a single form, based on interfaces.
1. My practice shows that, indeed, it is necessary. This has led me to understand its fallacy.
2. I don't remember it, and I prefer to have as few entities as possible accessible in each block of software.
1. it's never explained what it's for and what the fallacy is. Since this is a special type of data, you can set up access as you wish there. The example is clearly an unfortunate choice.
2. It is obviously wrong thinking to deny the programmer access to his data in his program under the pretext that he will make a mistake there since he will have to create all sorts of intricate workarounds to allow the programmer access and create unstable code with a lot of possible bugs on the way. It's like forbidding the driver to touch the steering wheel, and then inventing workarounds-interfaces how he can then steer the car instead of steering wheel.
2. Forbid a programmer access to their data in their program under the pretext that he allegedly would screw up there - it is obviously erroneous thinking, because then you have to create all sorts of sophisticated workarounds to give the programmer access and along the way unstable code is created with a bunch of possible bugs. It's like forbidding the driver to touch the steering wheel, and then inventing workarounds-interfaces how he can then steer the car instead of steering wheel.
No. Just anywhere in the code - only what is needed in that place should be available - everything else should be cut off, if possible.
In your situation with the driver - it means that it is reasonable to forbid the driver to touch the steering wheel while the car is parked. So he doesn't try to turn a wheel while the car is parked - in fact, at that time, wheel alignment sensors, for instance, can be connected to the wheels, and grabbing the wheel by the driver will lead to errors in setting those angles.
The idea is that at any given moment, only the functionality that the program needs at that moment is available to it, and everything else would be closed. I have long been convinced that this is the way to make the fewest mistakes.
No. Just anywhere in the code - only what is needed in that place should be available - everything else should be trimmed, if possible.
The idea is that at each moment only those functions are available to the program which are needed at that moment and all the rest must be locked. I learned a long time ago that this is the way to make the fewest errors.Constantly bothering with what to forbid and what to allow is obviously a very illogical requirement, unless of course the programmer is drunk when writing code and doesn't control himself that he might write a bunch of code he does not understand. I think that it will not help an alcoholic drunk programmer to avoid mistakes in code, and sober people do not need it in the first place.
Constantly worrying about what to forbid and what to allow is obviously a very illogical requirement, unless of course the programmer sits down to write code while drunk and has no control over himself that he can write a lot of code he does not understand. I think that it will not help an alcoholic drunk programmer to avoid mistakes in code, and sober people don't need it in the first place.
This is a very logical requirement that many people come to.
You don't need it - well... don't use OOP.