A question for OOP experts. - page 42
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
Clear classification. If we see that multiple objects have the same properties, it is logical to describe these properties in one parent object.
What if the object inherits properties and methods from different classes?
If we are dealing with a growing and dynamically rebuilding data structure (Knowledge Base), we need to use "inherited material" of already prepared objects to create new ones. In this case, objects will be synthesized by multiple inheritance, picking up extra inherited material. And therefore, will not function properly. That is, we will come to degenerate objects as soon as multiple inheritance begins. That's the problem...
What about when an object inherits properties and methods from different classes?
If we are dealing with a growing and dynamically reconstructing data structure (Knowledge Base), we need to use "inherited material" of already prepared objects to create new ones. In this case, objects will be synthesized by multiple inheritance, picking up extra inherited material. And therefore, will not function properly. That is, we will come to degenerate objects as soon as multiple inheritance begins. That's the problem...
The relevant toolkit is laid out. No one needs it but the author.
And there is also a need for one. But no one will need it either.
Same situation with KB, articles, etc.
Developers have introduced custom characters, services, ticks, caches, pips,.... I'm surprised they've done that, as it's only a few, if any, who need it.
Let's take the new pips mode of the tester. Who needs it? -No one in fact! It was born as a vision of a significant algorithmic optimization of the tester on the part of its developers. Who understood its usefulness? -Nobody! And so in everything.
Now the Tester is being significantly modified. But these modifications are of no use to anybody. Well, there are geeks who will appreciate it. In its current form, MT5-Tester is cooler than all its competitors. But for some reason they want to make it even cooler. No one is able to assess its current features, not to mention future ones. The developers are several heads above their users. And clearly the motivation for changes in the Tester is not monetisation (it simply cannot be, if no one understands it), but an internal desire to do something unprecedented.
In the new object, don't use properties of "left over" parents. I see some misunderstanding with you though. Why "give birth" to an object from one whose properties are not needed?
Needed, but not completely. The new object uses 3 properties of class A, 5 properties of class B, and 3 methods, of three other classes.
What should it do with the rest of the properties from these classes? How to restrict it from them?
Needed, but not completely. The new object uses 3 properties of class A, 5 properties of class B, and 3 methods, of three other classes.
What should it do with the rest of the properties from these classes? How to restrict it from them?
If a new object needs a heart, it does not need to inherit from a heart. The heart should be made part of the new object, as a member.
Inherit if the new object is an ancestor object. And use inclusion if the new object is WITH the other.
Pack 3 properties of class A into an object. Inherit from it. Or you can not inherit, but make an object with three properties a property of the required object.
Three properties to combine into an object and make a property of a new object? That's something to think about...
But, inheritance through many long chains generates similar problems at every step. The longer and more diverse the inheritance chains are, the more "mixing" of properties and methods the last generations of objects will get and the harder it will be to derive their individual chain to the base object.
If not inherited - there will be no access to the base object. If inherited, multiple "parentage" of objects prevents traceability of their direct chain to the base object.
It becomes increasingly difficult to isolate their own properties and methods from other classes.
Three properties to combine into an object and make a property of a new object? That's something to think about...
But, inheritance through many long chains generates similar problems at every step. The longer and more diverse the inheritance chains are, the more "mixing" of properties and methods the last generations of objects will get and the harder it will be to derive their individual chain to the base object.
If not inherited - there will be no access to the base object. If inherited, multiple "parentage" of objects prevents traceability of their direct chain to the base object.
It becomes increasingly difficult to extract their own properties and methods from other classes.
Peter, I highly recommend you
https://en.wikipedia.org/wiki/Code_Complete
If the heart is needed in the new object, it is not necessary to inherit from the heart. The heart should be made part of the new object, like a member.
Inherit if the new object IS the ancestor object. And use inclusion if the new object CONTAINS another one.
Three properties to combine into an object and make a property of a new object? That's something to think about...
But, inheritance through many long chains generates similar problems at every step. The longer and more diverse the inheritance chains are, the more "mixing" of properties and methods the last generations of objects will get and the harder it will be to derive their individual chain to the base object.
If not inherited - there will be no access to the base object. If inherited, multiple "parentage" of objects prevents traceability of their direct chain to the base object.
It becomes increasingly difficult to isolate their own properties and methods from other classes.