Crowdsourced GUI. Open beta testing. - page 21
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
You don't need philosophy to explain what an object is. For objects are parts of life itself.
There is the object 'living being'.
There is the object "insect", which is the heir to the object "living creature".
There is the object "mammal" which is the heir to the object "living being".
There is the object "human being", which is the heir to the object "mammal
There is an object "cook", which is the heir to the object "human being"
etc. etc. Where is the philosophy here?
The OOP clearly describes this mechanism of inheritance ( and not only inheritance)
Each object has a set of attributes and methods which are passed on inheritance. Everything is strictly logical and concrete. There is no philosophy at all.
Read articles by Artem Trishkin. His articles are not so obvious and tangible objects at all. For example, the "trading event" class. Or "event class". Or simply "class of a class."))
You can't do without philosophy.))
You don't need philosophy to explain what an object is. For objects are parts of life itself.
There is the object 'living being'.
There is the object "insect", which is the heir to the object "living creature".
There is the object "mammal" which is the heir to the object "living being".
There is the object "human being", which is the heir to the object "mammal
There is an object "cook", which is the heir to the object "human being"
etc. etc. Where is the philosophy here?
The OOP clearly describes this mechanism of inheritance ( and not only inheritance)
Every object has a set of attributes and methods which are passed on inheritance. Everything is strictly logical and concrete. There is no philosophy.
A hullabaloo to be had !!!
Will the automat kitchen be an inheritor of the "chef" class ?
spider-man, is he a specimen of which class ?
Let's have a chorus !!!
would an automatic kitchen be the successor to the cook class?
spider-man, is he an instance of which class ?
Man, I was writing and thinking about it, there's bound to be some smarty-pants. ))
But seriously, for spider-man and kitchen-machine there is such a topic, as multiple inheritance from virtual classes (I'm not sure about MQL, but it's exact in Java).
Man, I was writing and thought about it, there's bound to be some clever prankster. ))
But seriously, for spider-man, and automaton kitchen there is such a topic as multiple inheritance from virtual classes (I'm not sure about MQL, but it's definitely there in Java).
Incidentally, this is where OOP has a serious puncher going on. Multiple inheritance complicates the hell out of everything. As long as the objects are simple - everything is fine. But then a "vinaigrette" of inherited properties and confusion begins. The further it goes, the more confusing it gets.
By the way, this is where the OOP has a serious puncher going on. Multiple inheritance complicates the hell out of it. As long as the objects are simple, everything is fine. And then, a "vinaigrette" of inherited properties and confusion begins. The further it goes, the more confusing it gets.
This is called the diamond problem. This is what virtual classes are for. I've specified it, by the way.
Read primary sources and don't reinvent bicycles that have already been invented before you!
This is called the diamond problem. That's what virtual classes are for. I clarified that, by the way.
Read primary sources and don't re-invent bicycles that have already been invented before you!
Well, it's a nice name. An unsolvable problem. When I was thinking about creating a knowledge base, I realized that inheritance has a real and observable limit, beyond which the complexity overcomes the advantages. Inheriting properties from other objects would be less advantageous than re-creating them in new objects.
Zy. I'm off. That's enough for today).
Wow, that's a beautiful name. An unsolvable problem really. When I was thinking about creating a knowledge base, I realised that inheritance has a real and observable limit, beyond which the complexities override the benefits. Inheriting properties from other objects would be less advantageous than re-creating them in new objects. Everything has a limit.
Peter, start with a simple one. You still need to grow up to multiple inheritance. I'm not there yet (there's a bit left to go).
Wow, that's a beautiful name.
The name comes from the fact that the shape is a rhombus, which resembles a diamond.
A diamond-shaped inheritance.
The name comes from the fact that the shape is a diamond, which resembles a diamond.
Yes. At first, OOP generates a branching hierarchical structure. As it gets more complex, it grows. Objects arrange themselves on its branches. Gradually, the reverse process starts on top of it - branches begin to merge. This is how objects of multiple inheritance are formed. And then, the number of parallel connections between the classes grows so much, that the whole system gets absolutely tangled and no longer brings any benefit.