starting to move to OOP and MQL5 seems to be very frustrating!! - page 2

 
Alain Verleyen:
This topic is not about mql4 or mql5, it's about OOP, which is available and work the same on both languages.
^^ 100% agree with Alain.

Just because you can use OOP (in 4 or 5), doesn't mean you should. The vast majority of things you need to program in MQL will only ever require procedural, not OOP. Very easy to turn a simple 100 line procedural code into a 1000+ line monster in OOP for no added benefit but a #### load extra complexity. You should always aim to program the least amount possible for a given problem.
 
Does this mean you propose to use e.g. in the same EA both ways OOP and non OOP - would that make even more complex ...?
 
Carl Schreiber:
Does this mean you propose to use e.g. in the same EA both ways OOP and non OOP - would that make even more complex ...?

This depends from how you interpret complexity for yourself. For example, it's natural for me to use a profiling object, or a file object - which are both built on OOP - in any project, even which does not use OOP in other parts.

For me, just the thinking about OOP on itself - oh my Lord, am I using OOP or not in this case or that? - would be the most complex and useless practice. Do it simple. As a rule, if it's not a single buffer indicator, OOP is the simplest. For example even indicator with 2 buffers is already a good place to use OOP.

 
Stanislav Korotky:

...

For me, just the thinking about OOP on itself - oh my Lord, am I using OOP or not in this case or that? - would be the most complex and useless practice. Do it simple. As a rule, if it's not a single buffer indicator, OOP is the simplest. For example even indicator with 2 buffers is already a good place to use OOP.

Just curious. Why an indicator with more than 1 buffer becomes a good OOP candidate ?
 
Alain Verleyen:
Just curious. Why an indicator with more than 1 buffer becomes a good OOP candidate ?

Because initialization of many buffers is similar, and can be moved to a class. Someone could use just a no-OOP function, but you know that buffers can be different, and many settings can be applied - a class can hide this complexity (from the point of view of the client code using the class; the class itself will of course introduce additional lines of code, but this will eliminate much more lines of client code in all indicators based on the class) and provide decent default values/behaviours.

Because one of OOP principles is encapsulation (https://en.wikipedia.org/wiki/Encapsulation_(computer_programming)). I like when indicator buffers are declared inside an object. This makes sense even for single buffered indicator. But the more the buffers, the more probability of unexpected side effects. Placing all entities (including top-level functions) in the global context will eventually make the code a mess.

Encapsulation - Wikipedia, the free encyclopedia
Encapsulation - Wikipedia, the free encyclopedia
  • en.wikipedia.org
Encapsulation may refer to: Molecular encapsulation, in chemistry, the confinement of an individual molecule within a larger molecule Micro-encapsulation, in material science, the coating of microscopic particles with another material
 

I've just published several blog posts about OOP in MQL. I hope it will continue and may be helpful for those learning OOP with MetaTrader.

Feel free to ask questions and suggest new subjects to address in the series.

Reason: