What OOP code can do that procedural code can't ?

New comment
 

I am opening this topic in the hope to collect useful information about the advantages of object oriented programming versus procedural programming.

Also, this topic is language independent as mql4 and mql5 offer the same OOP language (except some new advanced features not yet available in mql4 at the time being).

I don't want a "war" between supporters and opponents of OOP, so this topic will be closely moderated, don't waste your time and mine please.

Please also provide examples and code to illustrate your point, not high theory or abstract concepts.

EDIT: while this topic is language independent, we are still talking about trading and mql4/mql5, so no "war games" or "apples and oranges" examples please.

 
In fact, I don't think there could exist a task which can not be refactored from procedural code to OOP or vice versa. The difference is in maintainability and readability of the code. For example, in procedural code you can reference global and/or local data (variables). In addition to these, OOP adds one more scope - object internal variables (state). It's very easy and natural to use them in OOP, and procedural implementation of the same logic would require some kind of workarounds with additional code and data structures. In other words OOP is just a shorter and nicer ways of coding.
 
 How do you want to build a workaround for overloaded virtual functions including the inheritance tree - which is the most important part of OOP? You seem to talk about structs, not OOP. 
 

OOP is designed to work and think like the nature beings , let's imagine if we want to develop a war game where we have vehicles with many types , soldiers with many skills and weapons with many specs.

developing this kind of a game without OOP will be a pain for the developer to keep track all these kinds of objects and to manage the data-structures and the memory well , and also to simulate the OOP features like inheritance  will be hard ( though it can be done ) , OOP made it easier to think and develop also esier to write read and debug the code .

some times having OOP more than necessary will make the code understanding and reading unfriendly(my personal point of view ) that i don't like

 
Stanislav Korotky:
In fact, I don't think there could exist a task which can not be refactored from procedural code to OOP or vice versa. The difference is in maintainability and readability of the code. For example, in procedural code you can reference global and/or local data (variables). In addition to these, OOP adds one more scope - object internal variables (state). It's very easy and natural to use them in OOP, and procedural implementation of the same logic would require some kind of workarounds with additional code and data structures. In other words OOP is just a shorter and nicer ways of coding.
I strongly doubt that OOP is a shorter way of coding.
 
Doerk Hilger:
 How do you want to build a workaround for overloaded virtual functions including the inheritance tree - which is the most important part of OOP? You seem to talk about structs, not OOP. 
"if...then...else..." statement should do the job.
 
Mohamed Hamdy:

OOP is designed to work and think like the nature beings , let's imagine if we want to develop a war game where we have vehicles with many types , soldiers with many skills and weapons with many specs.

developing this kind of a game without OOP will be a pain for the developer to keep track all these kinds of objects and to manage the data-structures and the memory well , and also to simulate the OOP features like inheritance  will be hard ( though it can be done ) , OOP made it easier to think and develop also esier to write read and debug the code .

some times having OOP more than necessary will make the code understanding and reading unfriendly(my personal point of view ) that i don't like

Forum on trading, automated trading systems and testing trading strategies

What OOP code can do that procedural code can't ?

Alain Verleyen, 2016.05.22 14:03

I am opening this topic in the hope to collect useful information about the advantages of object oriented programming versus procedural programming.

Also, this topic is language independent as mql4 and mql5 offer the same OOP language (except some new advanced features not yet available in mql4 at the time being).

I don't want a "war" between supporters and opponents of OOP, so this topic will be closely moderated, don't waste your time and mine please.

Please also provide examples and code to illustrate your point, not high theory or abstract concepts.

EDIT: while this topic is language independent, we are still talking about trading and mql4/mql5, so no "war games" or "apples and oranges" examples please.


 

I am a big fan of OOP - I cannot even  imagine I would go back to the procedural MQL. It is easier to make programs more complex. Anyway... the trouble with MQL is that a new user has it difficult to start here.

  • the built-in event methods are not OO. You have to hook into them,  which requires declaration of the listening objects in the root level. One of the basic OOP principles is compromised with this design.
  • there are missing 'system' code packages with common patterns. It prevents making compatible packages between users, and a serious OOP coder needs a lot of time to create his private ones. Unsupported class name prefixes (package names) are only a minor problem - when you cannot reuse the external code anyway.

So I would not recommend starting to learn the OOP right in the MQL. The coder needs to know what he needs to get it to work.

 
Alain Verleyen:
"if...then...else..." statement should do the job.
Uh come on ;) Not really ;) If something native could do the job somehow weird, then its pointers, but there are restrictions in MQL. If then else ... the code would become absurd. And if you accept absurd code as an answer to the question of this thread, then it obsolete at all ;) Do you agree that absurdity is a good frontier? Come on, say yes, just one time and just for my ego ;)
 
Doerk Hilger:
Uh come on ;) Not really ;) If something native could do the job somehow weird, then its pointers, but there are restrictions in MQL. If then else ... the code would become absurd. And if you accept absurd code as an answer to the question of this thread, then it obsolete at all ;) Do you agree that absurdity is a good frontier? Come on, say yes, just one time and just for my ego ;)

Sorry but no I will not say yes...a code is either reaching its goal or not, if it's working in accordance with the specifications, there is nothing absurd.

The question is "what OOP can do that procedural can't do" ? Stanislav was saying that OOP can do the same as procedural but in a "shorter and nicer" way. I tend to agree (except on the shorter idea but that's not that important).

 

Programming GUIs was what I did most all my time as a programmer. Its not possible to code a complete GUI which needs to communicate in several directions by if then else. You would need that much statements that the code would become unreadable and in the end also much too slow which would mean: Goal not reached, because I dont want to be forced to drink a cup of coffee after each click til I see the result.

Due to the circumstance that a CPU does not know anything about OOP, you can - of course - code everything without by just using pointers and complex arrays. But that is absurd. I could also hire 10000 people that draw my screen content on film in kinda realtime and beam it sequentially by a light projector on the wall. Is this also reaching the goal? 

12345
New comment
Reason: