A question for OOP experts. - page 6

New comment
 
Реter Konow:

The code is not portable - that's its peculiarity. It is not intended to be portable. It has another purpose. Well, the global scope of variables is a powerful tool for implementing complex mechanisms. You just need to know how to use it. When people tell me about hidden errors and bugs, I get confused. I never had any bugs related to global variable visibility. In a word, not at all.

The problem with global variables is that if the project is large enough and changes in the state of these variables come from many sections of code, it is quite time consuming to look for bugs.

Example. A bug is found because the value of a global variable is clearly not what it should be. There are a couple dozen of files and 100500 code lines in the project. No one remembers how many code fragments this variable changes. The result is a jar of coffee and a sound sleep with your head stuck in the keyboard.

And now the same thing, but OOP. We have written the code correctly and all fields are private. Accordingly, directly it is changed only in class methods, and from outside only by Set method. Accordingly, we put breakpoints on the Set method and how many methods there are in the class, where the field is changed, and we can easily track where changes are made and where they were changed incorrectly.

 
Реter Konow:

I never had any bugs related to global variable visibility. Not at all.

I don't even know how to convince you of the obvious, but I probably shouldn't, I don't get paid for it, do I?

What are you trying to do? Well, if you want praise, there you go:

Peter! Well done, keep it up!

))))

 
Vladimir Simakov:

The problem with global variables is that if the project is large enough and changes in the state of these variables come from many sections of code, it is quite time consuming to look for bugs.

Example. A bug is found because the value of a global variable is clearly not what it should be. There are a couple dozen of files and 100500 code lines in the project. No one remembers how many code fragments this variable changes. The result is a jar of coffee and a sound sleep with your head stuck in the keyboard.

And now we have the same thing, but it is OOP. We have written the code correctly and all the fields are private. Accordingly it will be changed directly only in class methods, but from outside only by the Set method. Accordingly, we put breakpoints on the Set method and how many methods there are in the class, where the field is changed, and we can easily track where changes are made and where they were changed incorrectly.

From practice. I have more than 100 connected files in my project. Some of them have more than 2000 lines of code. Global variables are used everywhere. I never had any bugs related to their globality. Maybe I've just adapted?)) Maybe there are no bugs because all variables are in Russian and all names are meaningful. No sdf or iukj. Therefore, I have no errors associated with them. In general, global variables are used for global event flags, e.g., opening a window, clicking on mouse buttons, expanding an ancient list, etc... Also, for focus. In other words, the mouse traverses through GUI, and numbers of all the objects and elements and their properties are written in global variables, and the required blocks are called from OnChartEvent, which immediately work with the objects and elements in focus. This is very convenient.
 
Igor Makanu:

I don't even know how to convince you of the obvious, but I probably shouldn't, I don't get paid for it, do I?

What are you trying to do? Well, if you want praise, there you go:

Peter! Way to go!

))))

I'm not achieving anything. Well, maybe understanding that it's not only with OOP you can write cool projects. And it is not only mastering OOP that is a sign of a developer. I don't argue that you can solve many tasks with OOP. But there are other approaches.
 
Thank you all for taking part in the discussion. I will try to get into OOP to really compare the capabilities of the two approaches. I'm interested in the hierarchy that OOP can provide, and if the usefulness of it isn't buried under its syntax, I'll definitely adopt it.
 
Реter Konow:
Well, maybe understanding of the fact, that not only with OOP you can write cool projects. And not only being proficient in OOP is a sign of a developer. I don't argue that you can solve many tasks with OOP. But there are other approaches.

it's not about OOP, it's about the principles of code writing themselves, this is the second time I've talked about it and@Vladimir Simakov wrote an example above

If you want to use global variable visibility - no problem, no one forbids it, you can do it - but quietly, while no one is watching! )))

but as a permanently used style of writing programs it is evil, and the more code, the more of this evil! - so you have explained? )))

SZY: one more test shot - look at MQL help, you see that all functions are made as separate, complete independent units? - passed the parameters = got the result! You think the Metakvot programmers are doing it all wrong again? We should use some free styles of writing functions - here in the global scope, and here the user will call the function and get the result! )))) - the procedural style (where each subroutine is a complete logical block) is the right code, write the codes correctly! not the right ... well, it will come on its own "when you need it fast" ;)

 
Реter Konow:
From practice. I have more than 100 connected files in my project. Some of them have more than 2000 lines of code. Global variables are used everywhere. I never had any bugs related to their globality. Maybe I just adapted to it?))

You just have a very good memory. Not everyone is that lucky. I already faintly remember which variables I entered today. I don't remember which ones from a week ago. But that's not a problem, they are all local and access to the fields of any object is through appropriate functions only. OOP allows me not to remember many things, I've already said more than once - ideally, in any place of code you should have access only to what you need and no more variables - so even if you want you can't change what you shouldn't. And when you really need to, you'll have to figure out why you can't access a variable- it's just an oversight, or more often it's a variable that needs additional work to be modified. If it were immediately available to you, you would forget about them, and then it would take a long time to figure out why the program doesn't work or doesn't work as you want it to.

 
Реter Konow:
I'm not trying to achieve anything. Well, maybe understanding that it's not only with OOP you can write cool projects. And it's not only mastering OOP that's a sign of a developer. I don't argue that you can solve many tasks with OOP. But there are other approaches.

Another good thing of OOP is that you gradually acquire class libraries, especially really universal ones, which remain with you all your life and facilitate this life.

From a real project, it really works. There's no hassle here, you just need to monitor the number and status of available orders/positions. This function only controls that the position/order is not closed/cancelled and removes it from the list after closing.

void OrdersControl(){
   for (CTrade* it=gPos.Begine();
        it!=NULL;
        it=it.Control()?gPos.Next():gPos.Delete());}

Where gPos is CList<CTrade> gPos

CList and CTrade are not from the standard library.

CTrade is inherited from my own library CPosition.

Actually below is all the CTrade you need just to make your project code readable:

#include "..\Header.mqh"

#ifndef _C_TRADE_
#define _C_TRADE_

#include "..\..\..\Shared Projects\mqlLib\Objects\Trade\CPosition.mqh"

class CTrade:public CPosition
  {
public:
                     CTrade(double mVolume,int mDirect,double mSL,double mTP);
   bool              Control() {return !( CPosition::Control()&TRADE_FINISH);}
  };
//-------------------------------------------------------------------------------------
void CTrade::CTrade(double mVolume,int mDirect,double mSL,double mTP):
   CPosition(NULL,
             mDirect>0?OP_BUY:OP_SELL,
             mVolume,
             0.0,
             mSL,
             mTP)
{}

#endif
The entire implementation of the order/position handling is hidden in the cross-platform CPosition library file.
 
Реter Konow:
Thank you all for taking part in the discussion. I will try to delve into OOP in order to really compare the capabilities of the two approaches. I'm interested in the hierarchy that OOP can provide, and if the usefulness of it isn't buried under its syntax, I'll certainly adopt it.

Help yourself on YouTube. There's a lot on there. Especially in English, which you're good with.


Don't spare 45 minutes, Peter. At the beginning it is very important to understand what this fellow is talking about. Many people will probably argue with him, but he's generally right:


 
Nikolai Semko:

Help yourself on YouTube. There's a lot on there. Especially in English, which you're good with.


Don't spare 45 minutes, Peter. At the beginning it is very important to understand what this fellow is talking about. Many people will probably argue with him, but in general he's right:


Thank you, Nikolai. I'll keep an eye out.
12345678910111213...55
New comment