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
Still, I don't get what "Object" is in the OOP.
It says "An object is an instance of a class". A class can have many instances. But, these instances are just references to the class. A class contains fields. The fields arethe properties of the object. Methods are engine elements that handle the values of specific object properties.
In my understanding, an object is a named (or numbered) set of properties. Property values are handled by various big block mechanisms. It's basically the same thing. Only it is written differently. In OOP, the functionality is fragmented for the sake of its encapsulation. In my case it is vice versa - merging of functionality.
If we turn the question into a graphics area, the CButton class is the same as my element Button. In my implementation, it's three objects in the kernel, each with a number of properties. In the class, it is also a list of properties (fields), methods of the button (I have no methods belonging separately to the button. Button functionality is inside global function blocks). In these blocks, button is treated as any element, but in certain places it has its personal conditions and handlers. In OOP, the same button functionality is encapsulated in a class accessed through instances.
George, in every library, in every solution, there is a concept. If I take someone else's concept and try to develop mine on its basis, I might get a concept crash, because a system built on two or more concepts cannot be stable. Therefore, innovative things have to be developed by yourself and from scratch. So as not to struggle with the "generic" errors and inconsistencies of the other authors.
Peter, you are arguing in vain. It is impossible to prove anything. I also do not understand this approach to programming when instead of using _Symbol they suggest to connect CSymbolInfo library and write object.Name().
I don't understand using such methods for example
What is the difficulty in writing
In both cases there is only one line of code.
On the other hand, Artyom showed me OOP possibilities, in which I got lost, didn't understand anything and don't use
Not so much.
Here's another way of explaining it. Usually nobody explains it that way.
All programmers know what int x, for example, is;
Now let's imagine that the word int is like the name of a class. And what does it describe ?
1. an integer
2. takes up 4 bytes in memory
3. takes values +- within some limits. (that much is enough);
And when we write int x; then we declare an object x, int type. x already physically occupies a 4 byte field in RAM.
Peter, you are arguing in vain. It is impossible to prove anything. I also don't understand this approach to programming when instead of using _Symbol they suggest to connect CSymbolInfo library and write object.Name()
I don't understand using such methods for example
What is the difficulty in writing
In both cases there is only one line of code.
On the other hand, Artyom showed me OOP possibilities, in which I got lost, understood nothing and don't use
In this variant of sense, the Class is a warehouse of tools, materials, raw materials and machines. Hierarchy of inherited classes - like the workshops of a "factory".
Peter, why would you want to go into such subtleties?
A class is a description of an object, its properties and methods for setting and accessing those properties.
An object is when we declare a variable of class type, or create a new object of that class using new operator.
For example, this is a class:
It has only two class members - type and name. These are its properties. And it's not an object yet. It's a plan, a blueprint, a blueprint... of the future object.
We create an object:
CClass class_obj; // Объявили переменную class_obj с типом класса CClass. Теперь class_obj - это объект
We create an object and a pointer to it:
George, in every library, in every solution, there is a concept. If I take someone else's concept and try to develop mine on its basis, I might get a concept crash, because a system built on two or more concepts cannot be stable. Therefore, innovative things have to be developed by yourself and from scratch. So as not to struggle with the "generic" errors and inconsistencies of the other authors.
There are only seven (!) notes. And how much music is on them? And no composer thinks about collapse. He just writes music that plays in the soul. He doesn't invent something else, he uses those seven notes.
Peter, why would you want to go into such subtleties?
A class is a description of an object, its properties and methods for setting and accessing those properties.
An object is when we declare a variable of class type, or create a new object of that class using new operator.
For example, this is a class:
It has only two class members - type and name. These are its properties. And it's not an object yet. It's a plan, a blueprint, a blueprint... ...of a future object.
We create an object:
We create an object and a pointer to it:
A class is a description of an object. Good. Contains the object's properties and functionality. Ok. All of 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).
I don't understand the use of SB methods such as
why is it difficult to write
the very concept of OOP implies just not writing - you don't need to 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 you only general information what you can do with a class - if you don't want to encapsulate CSymbolInfo, you can inherit it into your own class
HH: The whole point of OOP is to solve a given problem quickly and without knowledge of implementation.
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 things clear. At least VC++ in 21 days.
My advice for the first time is to use MFC, create a windows application based on CDialog, creating all sorts of objects and see how easy they are to manage.
After that you will throw away your venture. Unfortunately.