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
Peter, I highly recommend
https://en.wikipedia.org/wiki/Code_Complete
Peter. That's why I say no mindless inheritance. Clear separation and classification.
Here is an example:
The category "Fruit" is the base object.
Classes - "Fruit" and "Vegetable" are descendants of the "Fruit" class.
The "Fruit" class is the parent of the "Kiwi", "Mango", "Lemon", and "Orange" classes.
There is a new category "Citrus fruit".
Put it between the class "Fruit" and its successors - Kiwi, Mango, Lemon and Orange.
"Citrus is the parent for Lemon and Orange.
Next, - we cross Mango and Lemon and get - the Lee-Mango object.
The object partially contains citrus properties and partially non-citrus properties. It has TWO parents and this Hierarchy cannot be optimized.
So we have multiple inheritance of the Lee-Mango object and a double path to the underlying Fruit object: through the citrus chain and through the Mango chain.
In these chains, we have to bypass unnecessary Parent properties in order to preserve the personality of "Lee-Mango".
Peter, it's called: screwing your own brains out - coming up with insurmountable difficulties. You need to specify the task and make classes for it.
Why introduce an intermediate class called "citrus fruits"? Maybe the problem can be solved simply by adding the "citrus fruits" property to the dynamic list.
Peter, it's called: screwing your own brains out - coming up with insurmountable difficulties. You need to specify the task and make classes for it.
Why introduce an intermediate class called "citrus fruits"? Maybe the problem can be solved by simply adding the "citrus" property to the dynamic list.
And this. OOP is, after all, a programming tool, not a data tool (how do I put this right). The data tool is a database.
Three tables. One table has two columns: the id of the fruit and its name. The other has two columns: the id of the property and its name. The third has two columns: fruit id, property id.
As a result, it is possible to infinitely add new properties, assign them to the fruit, and thus obtain any new fruit.
The means of solving the problem must be appropriate to the task.
Peter, it's called: screwing your own brains out - coming up with insurmountable difficulties. You need to specify the task and make classes for it.
Why introduce an intermediate class called "citrus fruits"? Perhaps the task can be solved by simply adding the "citrus fruits" property to the dynamic list.
So be it.
But what about crossing the properties of the two objects which spawns a new object? The new object will partially inherit the properties of the other two objects.
How to implement its "partial" inheritance between several objects (its parents) and the base object?
So be it.
But what about crossing properties of two objects that spawn a new object? The new object will partially inherit properties of two other objects.
How to implement its "partial" inheritance from several other objects?
By applying an appropriate algorithm to solve this particular problem.
OOP is a programming tool, not a means of describing the world around, no matter how it corresponds to each other from some point of view.
And this. OOP is, after all, a programming tool, not a data tool (how do I put this right). The data tool is a database.
Three tables. One table has two columns: the id of the fruit and its name. The other has two columns: the id of the property and its name. The third has two columns: fruit id, property id.
As a result, it is possible to infinitely add new properties, assign them to the fruit, and thus obtain any new fruit.
The means of solving the problem must match the problem.
It's not about properties, it's about inheritance. That is, the distribution of properties and methods between objects.
New objects will link properties of previous objects in different combinations, which will increase the complexity of their chains to the base object.
It's not about properties, it's about inheritance. That is, the distribution of properties and methods between objects.
New objects will link properties of previous objects in different combinations, which will increase the complexity of their chains to the base object.
The objects themselves will not do this. Select properties of one fruit and properties of another fruit from the database, combine (leave something, discard something) - you get a new fruit - add it to the database.