A question for OOP experts. - page 2
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
In OOP, an "object" is a reference to a class in which its fields (properties) are declared. I understand an object as a numbered set of properties, each of which is a cell in an array. That is the difference.
The questions are not related to the topic of graphical interfaces. I have long bypassed graphical libraries and have nothing to look for there. But, I am now interested in the subject of AI, and this poses new challenges and questions.
Then take an off-the-shelf library, make friends with mql and go ahead. Why reinvent the wheel?
Explain what you mean by "...It's a static hierarchy. Constant and unchanging"?
In OOP, an "object" is a reference to a class in which its fields (properties) are declared. I understand an object as a numbered set of properties, each of which is a cell in an array. That's the difference.
Your call, but you are introducing the notion of ambiguity in the terminology at the outset
Explain what you mean by "...And we're talking about a static hierarchy. Constant and unchanging"?
)))))
he has his own terminology and we're playing "guess the tune".
SZZY: I changed jobs 5 times, but after the 2nd time I realized that to enter the team quickly, you need to learn to communicate in the same language as your colleagues, i.e. to be able to ask a question using technical terms generally accepted before - this is the most effective, otherwise you will get an answer "here are the manuals, go read them"))
Well, any category has a certain static set of concepts. It may be replenished, but its "foundation" is unchanged. Such static sets of concepts form a "static" hierarchy.
You mean that you have an object with a fixed number of fields, and you need to create a hierarchy of such objects? But any object has a static number of fields (as long as you don't change their number yourself in the class code).
I don't quite understand what you mean. Category - what do you mean? "Foundation"- what do you mean?
your case, but you are introducing a notion of ambiguity in terminology from the outset
)))))
He has his own terminology, and we are playing "guess the tune".
SZS: I changed jobs 5 times, but after the 2nd time I realized that to enter the team quickly, you need to learn to communicate in the same language as your colleagues, ie be able to ask a question using technical terms previously agreed upon - this is most effective, otherwise you get the answer "here are the manuals, go read them" )))
You mean that you have an object with a fixed number of fields and you need to create a hierarchy of such objects? But any object has a static number of fields (until you add them yourself in class code).
I don't quite understand you. Category - what do you mean? " Foundation - what do you mean?
An object with a fixed number of fields is different. There's a philosophical, not programmatic, context of concepts here. You should be well versed in this. In the philosophical view, an Object is an entity represented as a named set of properties. A property is an obligatory attribute of an Object and generally of any entity (process, state, value...). A category is a property rather than an object, and as a property it is a variable. Then the list of its subcategories is a list of its values in variable-property status.
Further, the category hierarchy is a static set of relationships. It reflects the nesting of the links in the hierarchy.
It is a picture of the world, represented as a knowledge base.
An object with an unchanging number of fields is different. There is a philosophical rather than programmatic context to the concepts here. You should be well versed in this. Philosophically, an Object is an entity represented as a named set of properties. A property is an obligatory attribute of an Object and generally of any entity (process, state, value...). A category is a property rather than an object, and as a property it is a variable. Then the list of its subcategories is a list of its values in variable-property status.
Further, the category hierarchy is a static set of relationships. It reflects the nesting of the links in the hierarchy.
It is a picture of the world presented as a knowledge base.
Peter, you make me out to be some kind of hardened philosopher. However, this is not true at all. I operate with an absolutely limited set of notions, which fit into the general concept of OOP.
If we talk about the picture of the world, any living being can be called an object. Every living being has its own set of qualities, which tell us unambiguously to which class of living beings it can be referred. But all living beings have basic properties, and they are unchangeable - is that what you meant by 'foundation'?
Peter, you make me out to be some kind of hardened philosopher. However, this is not true at all. I operate with a very limited set of concepts which fit into the general concept of OOP.
If we talk about the picture of the world, any living being can be called an object. Every living being has its own set of qualities, which tell us unambiguously to which class of living beings it can be referred. But all living beings have basic properties, and they are unchangeable - is that what you meant by 'foundation'?
Yes. That's right. Every Object has fundamental properties. And each belongs to a category, which in turn is nested in another category, and that in the next category, and so on, to the top of the abstraction. This "path" from any particular Object to its category, supra-category and supra-category is static. Therefore, I introduced the notion of a foundation, i.e. the immutable relations between categories. Hence the task of building a hierarchy arose. But perhaps memory and computer capabilities are not ideal for building complex, nested structures. Perhaps technical limitations will not allow this to be implemented efficiently.
Yes. Right. Every Object has fundamental properties. And every object belongs to a category, which is in turn nested in another category, which in turn is nested in the next category, and so on, up to the top of the abstraction. This "path" from any particular Object to its category, supra-category and supra-category is static. Therefore, I introduced the notion of a foundation, i.e. the immutable relations between categories. Hence the task of building a hierarchy arose. But perhaps memory and computer capabilities are not ideal for building complex nested structures. Perhaps technical limitations will not allow this to be implemented efficiently.
Creature.
Flora/Fauna
Subspecies
Species
Family
etc.
Is that what you want?
Well it's a simple inheritance from the base entity "Entity".
But you can go deeper than that - there are unicellular/multicellular, and that all applies to living things. But there are also non-living ones. It all depends on tasks you need to find properties of a base object, and inherit from them.
If you get really bang on your head, you could go as far as atoms and start dividing them into components in search of a fundamental parent object (caution - a fission reaction could become a chain reaction, and you would destroy half the world :))
How do you do an OOP loop on objects and their properties?
For example, I execute a loop as follows:
If I understand your code correctly, here is its OOP counterpart:
class MyClass { public: int _X_SIZE; color _this_state_color; int props[]; void Redraw(); }; MyClass* G_CORE[obj_total]; //Цикл по объектам в поиске нужного значения конкретного свойства. for( int a1 = 0; a1 < obj_total; a1++ ) { if( G_CORE[a1]._X_SIZE == THIS_SIZE ) { G_CORE[a1]._this_state_color = clrWhite; G_CORE[a1].Redraw(); } } //Цикл по свойствам в поиске неверного значения for( int a1 = 0; a1 < prop_total; a1++ ) { if( G_CORE[ELEMENT].props[a1] > Max_value ) { G_CORE[ELEMENT].props[a1] = Max_value; G_CORE[ELEMENT].Redraw(); } }