OOP vs procedural programming - page 27
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
In functional-procedural programming, the access problems you describe do not exist. Without overloading functions, without fields and objects, without pointers and stuff, when you only have one memory for all global variables that you can access from anywhere, how can the wrong function be called? What kind of access errors might occur? And it's a lot easier to remember everything.
It is a simple mistake - to refer to the wrong variable containing a value close in value.
Such an error may be undetected for a very long time, but, by the law of meanness, it "pops up" just at the time when error-free work in this place would be very much needed !
And it's going to be oh so hard to figure out... You're trying to understand why the Expert Advisor has closed a trade in a good trend when TS should not have closed it - and you can't. Everything seems to be working correctly.
This is exactly one of the most unpleasant mistakes - non-initialization of variables, or addressing the wrong one, but close by value. And the more variables are available in this or that part of the program - the greater the probability of this error.
Yes, of course, if you have a globally accessible graphical core, and you work with orders, it is really difficult to access the wrong variable. But in an earlier block where you detect the necessity of opening an order and address indicators for this purpose and probably according to user's actions - it's quite real to mix up variables.
You just keep the entire structure of the system in memory, and you don't see any problems here. If there are more structures, and important details periodically disappear from memory - you will come to the conclusion that the global access - is a source of problems, and you should avoid using it at all costs. And that the code should be written in such a way that you remember as little as possible. Ideally, do not keep anything in memory - each block has a name, indicating its function, at the input it receives data necessary and sufficient for this function, all that remains is to implement the function without involving any other knowledge "from the outside".
The simplest error is to refer to the wrong variable containing a value that is close in value.
Such an error may be undetected for a very long time, but, by the law of meanness, it "pops up" just at the time when error-free work in this place would be very much needed !
And it's going to be oh so hard to figure out... You're trying to understand why the Expert Advisor has closed a trade in a good trend when TS should not have closed it - and you can't. Everything seems to be working correctly.
This is exactly one of the most unpleasant mistakes - non-initialization of variables, or addressing the wrong one, but close by value. And the more variables are available in this or that part of the program - the greater the probability of this error.
Yes, of course, if you have a globally accessible graphical core, and you work with orders, it is really difficult to access the wrong variable. But in an earlier block where you detect the necessity of opening an order and address indicators for this purpose and probably according to user's actions - it's quite real to mix up variables.
You just keep the entire structure of the system in memory, and you don't see any problems here. If there are more structures, and important details periodically disappear from memory - you will come to the conclusion that the global access - is a source of problems, and you should avoid using it at all costs. And that the code should be written in such a way that you remember as little as possible. Ideally - do not store anything at all in memory - each block has a name, indicating its function, at input it receives data necessary and sufficient for this function, only remains to implement the function, not involving any other knowledge "from the outside".
Well, how can you call the wrong variable, if they all have different names? How can a wrong function be called if it has a unique name and no overloading? Inside the kernel array all of the cell indices are named with human words. What could be confused here? Understand, the problems you're talking about don't exist at all.
I only keep the kernel structure in memory, which is very simple. I also know the list of objects' properties. All the objects have the same properties, only the values are different. I have a total of 140 properties, but I keep in memory only the most important ones, about 30. The rest I remember when I need them. To do this, I open a file with defines and look at the full list of properties. Nothing complicated. Global variables in focus, as for example "OBJECT" or "WINDOW" don't need to be remembered at all. And it's impossible to mix it up with anything else.
My variables have meaningful names in Russian. You can only confuse things after a wild party).My global variables are the variables used in the focus, which are 'targeted' at the kernel and moved around as the cursor moves.
For example: the variable "WINDOW" constantly carries the number of the window at which the cursor is located. Variable "OBJECT" is the number of that object where the cursor is located.
I address a particular window, object and property in the kernel through them - G_CORE[WINDOW][OBJECT][_NAME] or G_CORE[WINDOW][OBJECT][_OBJECT_GROUP]. In any function, if I want X-coordinate of an object, I get it from G_CORE[WINDOW][OBJECT][_X], if I want height of an object - from G_CORE[WINDOW][OBJECT][_Y_SIZE] etc...
All in all, I have about a hundred separately declared global variables, but there are thousands of them in the global kernel array, because every cell in the array is a variable. However, it is very easy to manage this number of variables, because they are ordered. Each window in the kernel is an array field; each row is one object, which consists of 140 properties. Elements, in this case, are sets of objects. Each element has a master object, which contains the main properties of the whole element. Objects belonging to each element are linked by special indices so whatever the object comes into focus, the element it belongs to also comes into focus. So does the canvas on which it is drawn. Thanks to the explicit archetype of the kernel and direct access from any function, I can manage thousands of variables that are represented by kernel array cells without forgetting anything and without having to navigate around them.
A completely pointless conversation: there is no criterion for classifying code as "good" or "bad". This is why it is not clear about OOP.
For me, such criterion is the FEASIBILITY of the code, which manifests itself in the fact that the author or a third party can read the code and use it for modification, searching for bugs after quite a long period of time.....
Here above Fedoseyev has replaced the OOP switch. This particular example, maybe unfortunate, to me is a proof of the viciousness of OOP: clear code with a 100 position switch is replaced by a single line. To understand this line you have to go somewhere. It's not permissible for me.
The second example aboveby George Merts
When the clear code was replaced by NOT clear code after debugging. By my criterion the quality code (easy to read) was replaced by the code which is not acceptable for me.
That's why I have a question for all the OOP supporters: does a program becomes more vivid when OOP is applied and the example given by Fedoseyev on the switch is a failure or on the contrary, Fedoseyev's example very accurately characterizes OOP and OOP almost always leads to a loss of vividness?
Well, everything is clear with CC. Everything above the level of his understanding is unsightly. But he knows the letter R ))))))))))))))
Well, the CC is clear. Anything above his comprehension level is unattractive. But he knows the letter R ))))))))))))))
I'll add Chinese, maybe Japanese...
Why PLO? WHY would it be better?
Visibility is about simplifying debugging, modification. Visibility comes from careful program design, from structuring into FUNCTIONS and not OBJECTS, because the whole world is based on actions on objects, but not vice versa.
When the breakdown into functions is derived from the sequence of converting inputs into outputs. For example, converting a BUY|SELL input into an output is only possible by specifying an ACTION.
This is how human thinking works.
PS.
Regarding your comment about R.
Do you want to get sarcastic?
I answer very rarely, but I can.
How the hell can you call the wrong variable if they all have different names? How can the wrong function be called if it has a unique name and no overloading? Inside the kernel array all of the cell indexes are named with human words. What could be confused here? Understand, the problems you're talking about don't exist at all.
Well, I've had a couple of such cases.
Most often such errors occur when you copy a piece of code from another place and "fix" it according to current block. If you have global access - you may well miss changing one of the variables. If you only have access to what you have to work with in this case - then after copying - the compiler itself gives you a list of all variables and locations that need to be changed.
Tag Konow:
I only have the kernel structure in my memory, which is very simple. I also know the list of object properties. The properties of all objects are the same, only the values are different. I have a total of 140 properties, but I keep in memory only the most important ones, about 30. The rest I remember when I need them. To do this, I open a file with defines and look at the full list of properties. Nothing complicated.
30 properties ??? Well, that's unacceptable to me. Not that I can't remember them, but I don't want to rely on my memory. Much better, when in each block - you always have exactly those variables, which in this block should be processed, and there is no access to others.
But, it stresses me out having to remember... And since it's not hard for you - it's understandable that there's no point in doing unnecessary OOP fiddling.
Well, I've had a couple of these cases.
Most often errors of this kind occur when you copy a piece of code from another place and "fix" it to match the current block. If you have global access, you may well miss changing one of the variables. If you only have access to what you have to work with then, after copying, the compiler gives you a list of all the variables and locations that need to be changed.
30 properties ??? Well, that's not acceptable to me. It's not that I can't remember them, but I don't want to rely on my memory. Much better, when in each block - you always have exactly those variables, which in this block should be processed, and there is simply no access to others.
But, it stresses me out having to remember... And since it's not hard for you - it's understandable that there's no need to make unnecessary OOP-transactions.
Well, frankly speaking, I remember a lot of things. Just look at the abbreviations of snapping objects _X2X, Y2Y, B2B, R2R, H2Y, W2X, Y2H, X2W, C2C etc... each defines the position of one object in relation to the other. These are found in parameters A1,B1,C1,A2,B2,C2,A3,B3,C3,A4,B4,C4,A5... I also remember a couple dozen names of categories and subcategories of objects, a couple dozen properties of windows (more than 100 of them). There are dozens of functions in the build block, for example, and they take up more than 4000 lines of code. You have to navigate and remember a lot of them. But remembering comes from long practice, not at once, but gradually. My head used to get heavy from the amount of entities and code's size, but then it all got crammed in and became simple.
Well, frankly speaking, I remember a lot of things. The abbreviations for the object references _X2X, Y2Y, B2B, R2R, H2Y, W2X, Y2H, X2W, C2C, etc... Each defines a certain position of one object to another, are in parameters A1,B1,C1,A2,B2,C2,A3,B3,C3,A4,B4,C4,A5... I also remember a couple dozen names of categories and subcategories of objects, a couple dozen properties of windows (more than 100 of them). There are dozens of functions in the build block, for example, and they take up more than 4000 lines of code. You have to navigate and remember a lot of them. But remembering comes from long practice, not at once, but gradually. My head used to swell with the number of entities and size of code, but then it all got bogged down and became simple.
To distract myself, forgetting about everything, go on holiday for a month without thinking about the code. Then come back, see all these a1, b1, etc. and get hysterical :)
get distracted, forgetting about everything, go on vacation for a month, not thinking about the code. After coming, see all these a1, b1, etc. and get hysterical :)
For example, this is what the "checkbox" element in the proto-core looks like: