A question for OOP experts. - page 11
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
If a programmer enters the world of forex, there is no need to be a professional and know OOP.
It is better to learn the intricacies of the market and develop a profitable trading strategy. And it does not matter whether you use OOP or not. The profitability of the Expert Advisor will not suffer from it.
You don't have to waste your energy.
George, it's not just about memory. I have created a comfortable development environment for myself, using my native language and English as well. Bilingual code is remembered MUCH better than monolingual code. Especially when you're not stuck on standard words and call variables by any name you want. Proven. I simply ignored professionalism in programming and began to write as I pleased. As a result, I started to quickly navigate my code and easily read, recall and develop it. The rest you know...
I don't think it can help. For me the names of variables in any language wears out of memory almost instantly, I get up from behind the computer and already remember only the general principles, and cannot tell which variables have been entered in which place.
By the way, that's why I always use pairs of mqh-mq5 files instead of writing classes entirely in mqh files - I need to look into header files often, just to remind myself what's available in one or another case, I have the necessary header mqh files open in tabs and switch to them, when I need to refresh that information again. When whole class (and even more several classes) are described in one mqh file, it's harder to "hop" through this file, even with the help of tabs.
I can't keep all structure in my memory, although in my youth, as I already mentioned, I even wrote in assembler, but there are no other options - you only have memory addresses, and the maximum that macro assembler allows is to create names of specific areas using macrosubstitutions. This also works. But I have long ago got convinced that this way the number of errors is much larger and debugging of such code is much harder.
I already gave an example above: an error occurs and a variable is modified incorrectly for some reason. And the variable is accessed from a lot of places in the program. How to catch a place where there is an error? With OOP encapsulation it's very simple - we put a breakpoint in the interface function that modifies the variable, and as soon as incorrect modification occurs - we stop and immediately, by the call hierarchy, see where the incorrect modification was made.And with your approach, Peter, we have to dig through all code, looking through all places where this variable is accessed, putting breakpoints everywhere, and analyzing all calls, not only incorrect ones.
That's the thing, it can suffer. The friend of mine lost a part of his deposit because of an error in his code while OOP makes errors less probable.
It means he is not a good programmer. You can get more confused in complex OOP constructs than without it.
Classes must be applied where it is necessary. I have noticed that some programmers somehow have an obsession to apply many functions where they are not necessary. It happens the same way with classes.
Instead of writing a compact and short program without OOP, some programmers start applying classes, many functions and a simple solution turns into a kilometre long text.
It means he is not a good programmer. You can get more confused in complex OOP constructs than without it.
All other things being equal? I doubt it very much. If the complexity of the constructs is the same, it is much easier to make sense of them with OOP.
However it doesn't cancel the rule "with a cannon over a sparrow", it makes no sense to use large OOP complexities where the task is very simple and compact.
Although, as it was already said here - OOP allows us to build class libraries, which are then used in many projects.
Say, the same array classes, file classes... Even when you write a very simple indicator, without using OOP, it's much easier to declare a class CFile and use its functions, rather than use the standard functions of working with files.Not to mention the possibility to easily replace CFile with more specific ones, for example, I have a CLogFile class with an ability to automatically insert time and some additional data into strings (for log files) or CIniFile class, that can organize data into standard ini-files, and then read and use them when necessary.
It means he is not a good programmer. You can get more confused in complex OOP constructs than without it.
Classes must be applied where it is necessary. I have noticed that some programmers somehow have an obsession to apply many functions where they are not necessary. It happens the same way with classes.
Instead of writing a compact and short program without OOP, some programmers start applying classes, many functions and a simple solution turns into a kilometre long text.
Is it OK that the actual work is a hundred lines, and the remaining couple of thousand is a library written and debugged long ago? )))
If a programmer uses ready-made classes in his/her program, such as these: CTrade, CAccountInfo, CPositionInfo, it does not mean that his/her program is based on OOP.
It depends on whether the programmer creates such classes himself, or simply uses them without knowing the internals (at the source text level) of these classes.
....
An example has already been given above - an error has occurred, for some reason a variable is incorrectly modified. And the variable is accessed from a bunch of places in the program. How to catch a place where error ? With OOP encapsulation it's very simple - we put a breakpoint in the interface function that modifies the variable, and as soon as incorrect modification occurs - we stop and immediately, by the call hierarchy, see where the incorrect modification was made.And with your approach, Peter, we have to dig through all code, looking through all places where reference to this variable occurs, putting breakpoints everywhere, and analyzing all calls, not only incorrect ones.
Yes, my kernel is modified in all parts of the program and errors happen, but I do not need breakpoints. I calculate in my mind and alert in several places to check values. That's how I find it. I stress - I know my program very well.
But, on the plus side, with this knowledge, no syntactic obstacles and a native language, I have huge opportunities for rapid development. And that's why I'm against OOP in my solutions.
Splitting the code, its alien monolinguality, new syntax, additional rules - all this will slow down the development of the program. I will lose more effort and get less result. I know this for a fact.
If my task was to build and debug a program from ready-made pieces of code, only OOP and libraries would do. Hooking up and developing new solutions are different things. Many people advocate OOP because they want to use chunks of other people's code and save effort. I create my own solutions using proprietary technology and I have different needs and views on OOP.
Yes, my kernel is modified in all parts of the program and errors happen, but I do not need breakpoints. I calculate in my mind and alert in several places to check values. That's how I find it. I stress - I know my program very well.
But the plus side is that with such knowledge, absence of syntactic obstacles and native language, I have huge opportunities for rapid development. And that's why I'm against OOP in my solutions.
Splitting the code, its alien monolinguality, new syntax, additional rules - all this will slow down the development of the program. I will lose more effort and get less result. I know this for a fact.
If my task was to build and debug a program from ready-made pieces of code, only OOP and libraries would do. Hooking up and developing new solutions are different things. Many people advocate OOP because they want to use chunks of other people's code and save effort. I create my own solutions using proprietary technology and I have different needs and views on OOP.
I advise to use VC++ dialog box template at least once, create application based on CDialog from MFC, set all sorts of Controls on it in visual mode, use ready-made functions to understand all the power of OOP.
And I'd also like to add that Borland C++ has very handy classes to work with Oracle. I worked with it till 2012, I don't know how now.
I advise to use VC++ dialog box template at least once, create application based on CDialog from MFC, set all sorts of Controls on it in visual mode, use ready-made functions, to understand all the power of OOP.
And I'd also like to add that Borland C++ has very handy classes to work with Oracle. I worked with it till 2012, I don't know how now.
it's the second half of 2019.... but both the 20th and the 25th and .... Will also argue about the need to use OOP?
))))
if we like it, we use it, if we don't like it, we don't use it.
if you got used to write programs by using previously written small subroutines - write, you got up on the wrong side of the bed... you put all these subroutines in the source code and you get one big mess of code
give people a lot of possibilities of the open source, it's still not the same, trim functionality to pure C, again it's not the same ))))
ZS: I suspect that some of the developers are reading the forum anyway... I think this thread will definitely cheer them up! ))))