A question for OOP experts. - page 24

 

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.

 
Реter Konow:

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

//+------------------------------------------------------------------+
//| Set the property value "SYMBOL_SELECT"                           |
//+------------------------------------------------------------------+
bool CSymbolInfo::Select(const bool select)
  {
   return(SymbolSelect(m_name,select));
  }

What is the difficulty in writing

SymbolSelect("Нужный символ", включить или выключить);

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

 
Petros Shatakhtsyan:

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.

Thank you. In this case - a class is an encapsulated entity, a container that is essentially an Object in itself, in a hierarchical relationship with other object-classes. A class describes its entity through properties (fields) and methods (encapsulated functionality), separated from the functionality of other objects.
 
Alexey Viktorov:

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

Nothing :)) Trying to understand the concept of OOP to find differences and similarities with my concept. I think it will enrich my knowledge.))
 
Реter Konow:
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:

//+------------------------------------------------------------------+
class CClass
  {
//--- Приватные члены класса. Доступны только в объекте этого класса
private:
   int               m_type;  // Тип объекта

//--- Защищённые члены класса. Доступны в объекте этого класса и его наследниках
protected:
   string            m_name;  // Имя объекта

//--- Публичные члены класса. Доступны везде
public:
   void              SetType(const int type)          { this.m_type=type;     }
   int               GetType(void)              const { return this.m_type;   }
   void              SetName(const string name)       { this.m_name=name;     }
   string            GetName(void)              const { return this.m_name;   }
  };
//+------------------------------------------------------------------+

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:

CClass  *class_ptr = new CClass();  // Оператором new создали новый объект класса CClass, и в переменную class_ptr получили на него указатель. 
                                    // Теперь в памяти сидит объект CClass, и получить к нему доступ можно по этому указателю, 
                                    // и по этому же указателю обязательно удалить объект по завершении работы оператором delete
 
As I said before, the OOP view of the Object is broader than my concept. I only dealt with graphical objects, with a monotonous set of properties. OOP offers a view of any entity through the concept of Object. This is of course great, because any entity is an Object. Of course, I'm against excessive encapsulation and fragmentation of object functionality. Why? Yes because it makes mechanisms less efficient. But, the very possibility of looking at the Object in a broader context appeals to me.
 
Реter Konow:

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.

 
Artyom Trishkin:

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).

 
Alexey Viktorov:

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:

SymbolSelect("Нужный символ", включить или выключить);

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.

 
Реter Konow:

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.

Reason: