A question for OOP experts. - page 10
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
And so am I - little by little... and full understanding only comes after 4-5 years (and this is normal for an ordinary person)
In my opinion, "full understanding" is not necessary. The main thing is to "grasp the essence". Me, when I got acquainted with OOP meodology, it was 1995.
I already had some experience with "regular C" in the spirit of K&R (oldfags must remember), besides I used assembler functions quite often. At first I was rather skeptical about OOP ideas, not even so much because the programmer had to perform some extra actions, but because of pure CPU "overhead". But I was soon convinced of the usefulness of this technology and theCString class was the main "switch" in my mind.
Not only that, but working with strings was much simpler: at that time we were writing a data packer and my part was the input text analyzer. Consequently, it appeared to be very convenient to create a hierarchy of various strings on the basis of the CString class, which had important differences for our packer.
I especially liked the fact that after the data packer had been written, the task of using it for strings, which had a lot of digital information, which the packer was not originally designed for, came up. It certainly packed such data, however, it did it considering input alphabet as just characters, but knowing that the string consists of some words and digits - it significantly improved the packer without speed loss. So, a class representing such strings with digits (and also a specific compressor for digits) was written, everything was added to existing classes and the packer started working with new data, although this functionality was not expected initially.
That's when I really appreciated the potential of OOP to modify and maintain code. Of course, there is some CPU overhead, but it is more than compensated by reduced work of programmers.
That is why I recommend everyone who starts learning OOP to start with such tasks, where the advantage of OOP would be well and clearly visible. That is, with the tasks of processing different objects in lists, which would represent instances of classes with a common ancestor.Look, I have this channel in my subscriptions, in general I have a positive opinion of the author, and there is even a repeat of the topic of your video for which the argument began:
I almost completely agree with all thoughts in the video. There are a couple of minor not even objections but clarifications (for example, I consider NULL to be a very useful pointer, which tells about an error, you just should bear in mind that function can return this null pointer, and, of course, the video correctly says - you cannot work with it as with an object).
And everything else about inaccuracies, order of development, getter-setters and the same NULL is correct.
Kudos to the author.
It is strange that being a philosophical and well abstracted person, I am so desperate to reject the professional's beloved approach to programming. While it was designed to be practical, OOP has become overgrown with entities and redundant to its tasks. "Redundancy" of tools hampers the solution, as well as scarcity. And this redundancy is undoubtedly a consequence of marketing. Come to think of it, a minimal OOP is enough to solve everything in the field of computer problems. Just as everything can be created with simple functions and proper memory handling. At the initial level, I adopted OOP right away. Then I noticed that some entities could not justify the necessity of their existence and lived their own, abstracted from tasks, lives inside the growing concept. Yes, they are embedded into solutions, but they are parasitic on developer's intelligence. They slow down the work process, reducing its efficiency. They hinder the workflow by obfuscation, syntax, rules... That's what I don't like about this optionality inside the solution.
So, I'm going to use the most minimal OOP. The one that was created before marketing it.
It is strange that being a philosophical and well abstracted person, I am so desperate to reject the professional's beloved approach to programming. While it was designed to be practical, OOP has become overgrown with entities and redundant to its tasks. "Redundancy" of tools hampers the solution, as well as scarcity. And this redundancy is undoubtedly a consequence of marketing. Come to think of it, a minimal OOP is enough to solve everything in the field of computer problems. Just as everything can be created with simple functions and proper memory handling. At the initial level, I adopted OOP right away. Then I noticed that some entities could not justify the necessity of their existence and lived their own, abstracted from tasks, lives inside the growing concept. Yes, they are embedded into solutions, but they are parasitic on developer's intelligence. They slow down the work process, reducing its efficiency. They hinder the workflow by obfuscation, syntax, rules... That's what I don't like about this optionality inside the solution.
So, I'm going to use the most minimal OOP. The one that was created before marketing it.
Yeah. You create a class, for example, to work with a file. You start using it and you get bugs. You close one part of the code and try to do something with it in the other part. There are two approaches. The first one is to try to always remember where something is made and even with one developer this may not be very good. The second - before the action of checking operations to do. Okay, the next bug: in verification operations, which are scattered throughout the code, here and there typos, wrong sign, corrected in one place, forgot in another, etc. As a result, you have gone from such a beloved efficiency of code to a trivial and simple thing: every Read/Write method and the like includes a call to a check method, allowing you to undo it when you call it, which you will almost never use. And then you realize that this is a good thing, because modern hardware allows you not to count clock cycles and memory consumption in 98% of solved tasks.
Yeah. You create a class, for example, to work with a file. You start using it and you get bugs. You close one part of the code and try to do something with it in the other part. There are two approaches. The first one is to try to always remember where something is made and even with one developer you may fail to do that.
Peter is good at it.
That's the problem - Peter is comfortable using a huge table of all variables, which is always available from the whole program, and from which he takes what he needs at any time. For the titan of memorization, this is quite handy.
In OOP encapsulation is an archival feature, which is just used to ensure that the user anywhere in the code only has access to the variables that he needs and no other variables. But for Peter it is a minus, he already remembers where, what and how he used. He wants to be able to access any variable in any part of the program at any time. He doesn't like my approach, when in order to access a variable you must first get a pointer to the interface, and from the interface you must get the function, and only then it returns the value you need. And at any of these steps, you may encounter an access restriction. I think this is a good thing, because if there is a restriction - it's put in for a reason, it means that I haven't considered some important details. And for Peter, it's a hindrance, because he always takes everything into account.
Yes, you have created a class to handle, say, a file. You start using it and get errors. You close one part of the code and try to do something with it in the other part. There are two approaches. The first one is to try to always remember where something is made and even with one developer this may not be very good. The second - before the action of checking operations to do. Okay, the next bug: in verification operations, which are scattered throughout the code, here and there typos, wrong sign, corrected in one place, forgot in another, etc. As a result, you have gone from such a beloved efficiency of code to a trivial and simple thing: every Read/Write method and so on has a call to a check method with an option to undo this call, which you will almost never use. And then you realize that this is a good thing, because modern hardware allows you not to count clock cycles and memory consumption in 98% of solved tasks.
Let's imagine the opposite situation. Well, you don't have bugs. Not at all and almost never, because you remember ALL and take ALL into account! Would youuse OOP just because of your "professional duty"? I don't think so. What would you care about then? - Only the efficiency of your codes. You will try to remove all the overhead, so that the code would work as quickly as possible. You will also try to create your code in such a way that it develops quickly.
When people tell me about bugs that occur here and there I understand them, but when they are associated with the use or non-use of OOP I don't agree. The number of bugs depends upon one's knowledge and understanding of one's code. One who writes the code better knows it than a person who plugs it in. One who writes it always has fewer bugs. As you understand, OOP promotes portability of code the reverse side of which is poor understanding by other programmers. That is the source of bugs.
I write everything myself, and I find bugs in blocks of 2000 lines without profiler and checker functions. Simply, I know my code. Best cure for bugs.))
It works for Peter.
That's the problem - Peter is comfortable using a huge table of all the variables, which is always available from the whole programme, and from which he takes what he needs at any time. For the titan of memorisation - it's quite handy.
Encapsulation in OOP is an archival feature, which is precisely used to ensure that the user has access only to those variables that he needs in any place of code, and no more. But for Peter it is a minus, he already remembers where, what and how he used. He wants to be able to access any variable in any part of the program at any time. He doesn't like my approach, when in order to access a variable you must first get a pointer to the interface, and from the interface you must get the function, and only then it returns the value you need. And at any of these steps, you may encounter an access restriction. I think this is a good thing, because if there is a restriction - it's put in for a reason, it means that I haven't considered some important details. And for Peter, it's a hindrance, because he always takes everything into account.
George, it's not just about memory. I've created a convenient development environment for myself, using my mother tongue and English too. Bilingual code is MUCH better to remember than monolingual one. 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. Further you know...
ZS. Don't let them think I'm urging you to give a damn about professionalism. Absolutely not. I spit on it because of my over-inflated ego. It turns out that it can be not only bad, but also good. :)
Peter, your thinking suggests that you have never worked in a team. You haven't seen how everyone does their own piece of a huge task, and how it all comes together at the end.
For example without OOP, it was impossible to create and develop Windows.
If it wasn't necessary, I would try not to apply classes either. But when I decided to turn my robot into a multicurrency robot, I immediately applied classes, because it was already clear what would happen without OOP.
By applying classes, it's obvious that the object pairs used are of the same class and working with them simultaneously is already very easy.
Peter, your thinking suggests that you have never worked in a team. You haven't seen how everyone does their own piece of a huge task, and how it all comes together at the end.
For example without OOP, it was impossible to create and develop Windows.
If it wasn't necessary, I would try not to apply classes either. But when I decided to turn my robot into a multicurrency robot, I immediately applied classes, because it was already clear what would happen without OOP.
By applying classes, it's obvious that the object pairs used are of the same class and working with them simultaneously is already very easy.
Yes, I wasn't part of the team. My approach should be considered as an experiment of one developer. I'm not persuading to follow it. There is too much impertinence in my approach.)
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.