A question for OOP experts. - page 25
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
the very concept of OOP implies just not writing - you must not know the implementation of the method (in your example return(SymbolSelect(m_name,select))
Imagine that instead of this line:
you have to do a lot of queries, various checks etc. - This will take you time to write your own library and study the material
Suppose your task is just to use only one method of ready-made solution in the form of a class - you create an instance of the class (object) and use ready-made Select(const bool select) method
If you are not going to perform such operations, free up memory = delete the object
Suppose your task is to display a button, by pressing it, you enable/disable the symbol in the market watch ---> create your class and encapsulate ready-made class button and ready-made class CSymbolInfo - the task is done
The OOP paradigm gives only general information what can be done with a class - you don't want to encapsulate CSymbolInfo - well, inherit your class from it
I believe, I don't understand and I don't accept it. When you have a specific task that can't do without all these caveats, then the "mental enlightenment" and understanding will come. But for now, from my point of view, just fancy gadgets arenot always justified. Not always doesn't mean never. I'm happy to use Ctrade class, but I don't take it as mentioned above. If the description of SymbolSelect function in documentation is not difficult to find, in SB it's already difficult to find the description.
HH: "On a nutshell", the essence of OOP is a quick solution to a given problem without knowledge of the implementation.
In that case, instead of knowing the implementation, you have to know how to call the desired method, where to find it and so on. Is this a kind of language in a programming language?
Well, I can understand if one project needs to have several instances of an object. But so far I haven't seen any such implementation, except for Artem's demonstration mentioned above. In that case it is clear that it is better, easier, simpler, but I did not come to a full understanding precisely because of needlessness, lack of task. It doesn't make sense to change the object for the sake of a single use of mql5 functions. That's my reasoning.
In that case, instead of knowing the implementation, you need to know how to call the right method, where to find it and so on. Is this a kind of language in a programming language?
look in the documentation, everything that is posted publicly is accompanied by manuals, so to speak, ethics
it's not a style, it's a paradigm! - a concept, rules of etiquette, no one is forced to write so, but for some reason it is the most common style
the essence of OOP is to solve a given task quickly without knowledge of the implementation
You can call a function, passing a structure with data into it, and get an equally fast solution without knowledge of the function's implementation.
Yes, but your method will be limited, in OOP you can also inherit - even without knowing the implementation and add to your task, the first thing that comes to mind - Button with rounded edges, there are tons of examples on the web
SZZ: and the logic of unfolding an object through constructors is pretty handy.
A class is a description of an object. Good. Contains the object's properties and functionality. Ok. All this is ordered, open or protected.
Then the OBJECT itself is out of the picture. It is in the context of the class. In the context of its name and description. That is, in OOP, the Object, is exactly a set of attributes (not only properties, but also functional elements - methods), but more ordered and encapsulated than I have. (It makes more sense to me).
You have to read books to make sense of it. At least VC++ in 21 days.
I advise you to use MFC for the first time, create a windows application based on CDialog, creating all sorts of objects and see how easily they are managed.
After that you will throw away your venture. Unfortunately.
Well, that's unlikely. The point is that I found very few conceptual differences between my approach and OOP. My approach is also object-oriented. Objects are encapsulated in the kernel and have a very specific representation. They are linked by pointers, forming complexes - elements, windows... If you go beyond graphics and create a different form of kernel which includes more diversity, it will be as good as in OOP.
The difference in approaches is in the style of writing code, syntax and methods of distributing functionality. In my approach functionality tends to merge, in OOP it tends to split. Merging of functionality is guaranteed to increase efficiency of the system and small amount of syntax, while splitting of functionality facilitates portability of the code. It allows for plugging of modules. Generally speaking, these are the differences.
Of course, my approach does not yet have that broad "objectivity". But, I already have thoughts on how to fix this. A kernel is of a single type and this limits the properties stored in it, but a kernel doesn't have to be a single matrix. It can be a complex of kernels. The main advantage is the digital representation of objects, which does not require a long description, additional syntax, and fragmentation of functionality.
But, OOP is very interesting to me. I will learn from it.)Peter, finally google classes, what they are in the context of memory allocation, method calls, i.e. what the compiler converts it all into. Most of the questions will evaporate on their own after that.
A lot of thought has gone into the concept of OOP, and here's what:
Let's abstract away from syntax and technical terms, leaving the concepts of "Class", "Object", "Property", "Encapsulation", "Polymorphism", "Inheritance". I will describe the philosophical "root" of the concept.
Reality is perceived by consciousness through prisms of "Space", "Time" and "Matter" (this is how the sense organs work), while "Object" is a discrete result of their continuous interaction.
The multiplicity of forms of interaction generates a variety of objects that are "planted" by the unconscious of the subject on a certain "framework". This framework has a branching, cascading structure and is "built" into the unconscious, being one of its "archetypes". The framework takes on new and new objects (information about them) that are distributed throughout its structure. This is where the concept of OOP comes from.It is a conscious distribution and binding of objects imitating the "algorithm" of the unconscious. Having mastered the methods of one's own thinking the subject is able to simulate its work in the "tracing" mechanism of the brain - the computer. Even if a computer is just a pathetic parody of a brain, but man himself perceives only shadows of the objective world. The cascade, branching archetype, is a "pattern" of distribution of objects, properties, processes and all information inside our memory in general. It is a biological tool to simplify the perception of reality, structuring a model of the world around us. It is given to us by Nature. Awareness of our own "natural" (i.e. unconscious) information processing mechanism is a level of self-awareness necessary touse OOP.
Consider this implicit, biological, "tree-like" archetype that facilitates memorisation, learning and perception, in the context of its "artificial" application.In OOP, we "produce" objects by encapsulating their descriptions in classes, where we establish their properties and values. The relationships of objects are reflected in their classification, and implemented through the inheritance of properties and methods from global to private. Practically, it looks like this: every private object is just an object and therefore has all the properties of just an object + its private properties. Derived objects will have its private properties as their common properties, but will have their private properties. Further, the chain can branch indefinitely. It is the same with methods of objects. A method reflects an action, an interaction, a process, a change of states. Methods of objects are distributed from general to private like properties. If there is a general process, each discrete form will have its own properties. And this is polymorphism. That is, unlike overloading, polymorphism provides a different private implementation of an underlying function while retaining its underlying mechanism. This is "functional" inheritance.
As we can see, "tree-like" in OOP is everywhere; whatever schemes you come up with, you will still get a "tree"). But this is correct as we are just copying our own unconscious patterns of working with information.
Been thinking a lot about the concept of OOP and this is it:
...Tough.
Peter, you need to get into politics. Such talents are not in demand here - to say much, cleverly and incomprehensibly, and about nothing.
...
With a better understanding of how our conscious and unconscious minds work, we will be able to replicate their mechanism in the computer. I simply stepped back from the technical details and looked at the root of the concept.