Response to Lattice Inheritance
This publication is a response to the text "Lattice inheritance" , published by the user potan , with an alternative proposal, to the subjective opinion of the author, closer to the OOP with classes (for the case with a limited set of classes).
"The goal of inheritance is to bind the code (set of methods) to the minimum set of properties of an entity (usually an object) that it provides and that it needs."
Is this so? Also, what is the reason for the binding? By what signs do we conclude that these methods should be connected with this object, while others should be made part of other objects that will take the missing properties / parameters through public interfaces?
I adhere to SOLID and the idea of sole responsibility for the object. Consequently, the hierarchy of inheritance in this case - it clarifies the responsibility to the specific circumstances in which it must be executed.
')
However, objects in the real world (or the subject area) may carry several different functions / responsibilities, therefore, direct mapping them to the class system may fail. I see such an object in the class system of an application as a set / container of the responsibilities supported by the domain object. The task of this class is to coordinate responsibility among themselves. Reconciliation takes place partly through specific descendants of responsibilities, partly inside the container class.
I will try to give an example close to the example of the article.
Skills
Skill - provides general information, such as a link to a skill tree and a slot for skill items.
The ability to shoot - provides an opportunity to aim, in the slot of skills there should be a shooting weapon.
The ability to shoot MANPADS - specifies the implementation of the function to aim, for example, MANPADS screen draws.
The ability to swim - allows you to dive into the water (for example, without dying at the same time) and shows the time scale, the character flies in the water.
By the way, here I missed the abstraction - the ability to move, from which you can inherit the ability to swim and walk.
Then the specific characters will contain skill sets.
Character:
Foot Soldier (Character):
Duck (Character):
The responsibility of the character - to coordinate with each other his skills and switch them. For example, when a character enters the water. If you have the ability to swim - activate it, otherwise - draw a picture of a character sinking.
Question: What will happen if this kit grows?
And how can it grow?
New skill:
If these are quantitative things, for example, MANPADS fired with a probability of hitting 0.6, and now 0.8 - so these are just different entries in the database of the same class.
.If something new, for example, a sword, then in any case, a mountain of code is needed, which at the beginning will abstract the possession of the sword, and then each character will add its own details. Although not necessarily a complex modification (if the abstractions of the Character and his heirs are good).
A new class of characters - here you need to describe the combination of skills, how to coordinate them with each other. Code as in a character subclass, it is possible to select individual skill subclasses adapted for a new character.
It is more difficult for an existing one to add something else, since you need the internal code of the existing iterate again. And it may be easier to inherit a descendant.
For example, the Duck suits us all, only he does not know how to shoot. So, this functionality should be imposed, it may be more convenient to add 2 classes at once: Simple Duck and Duck, who can shoot. And in the Duck class, leave common responsibility for the daughter ducks - the ability to swim - adapted to the duck: in the form of swimming and diving.
Another side of the difficulty is to add a new responsibility (class). There is a need to correlate it with all existing ones. Potentially, this process can go to infinity, and the more existing classes, the longer it will be. The help in this is design from top to bottom: there is a world, it creates characters and allows them to interact by means of skills. Characters skills can gain / lose.
From this position, mixin seems to be an undefined class. It was left undefined due to the desire to make faster and not to rebuild the existing hierarchy of classes and their composition.
"The goal of inheritance is to bind the code (set of methods) to the minimum set of properties of an entity (usually an object) that it provides and that it needs."
Is this so? Also, what is the reason for the binding? By what signs do we conclude that these methods should be connected with this object, while others should be made part of other objects that will take the missing properties / parameters through public interfaces?
I adhere to SOLID and the idea of sole responsibility for the object. Consequently, the hierarchy of inheritance in this case - it clarifies the responsibility to the specific circumstances in which it must be executed.
')
However, objects in the real world (or the subject area) may carry several different functions / responsibilities, therefore, direct mapping them to the class system may fail. I see such an object in the class system of an application as a set / container of the responsibilities supported by the domain object. The task of this class is to coordinate responsibility among themselves. Reconciliation takes place partly through specific descendants of responsibilities, partly inside the container class.
I will try to give an example close to the example of the article.
Skills
- ability to shoot
- MANPADS MANUAL
- swimming skills
- walking ability
Skill - provides general information, such as a link to a skill tree and a slot for skill items.
The ability to shoot - provides an opportunity to aim, in the slot of skills there should be a shooting weapon.
The ability to shoot MANPADS - specifies the implementation of the function to aim, for example, MANPADS screen draws.
The ability to swim - allows you to dive into the water (for example, without dying at the same time) and shows the time scale, the character flies in the water.
By the way, here I missed the abstraction - the ability to move, from which you can inherit the ability to swim and walk.
Then the specific characters will contain skill sets.
Character:
- current movement skills;
- skill list: [].
Foot Soldier (Character):
- current ability to shoot;
- list of skills: [swim, walk, shoot MANPADS].
Duck (Character):
- skill list: [swim].
The responsibility of the character - to coordinate with each other his skills and switch them. For example, when a character enters the water. If you have the ability to swim - activate it, otherwise - draw a picture of a character sinking.
Question: What will happen if this kit grows?
And how can it grow?
- add a new skill;
- add a new character;
- add an existing character a skill that previously was not peculiar to him (to teach a duck to shoot from MANPADS).
New skill:
If these are quantitative things, for example, MANPADS fired with a probability of hitting 0.6, and now 0.8 - so these are just different entries in the database of the same class.
.If something new, for example, a sword, then in any case, a mountain of code is needed, which at the beginning will abstract the possession of the sword, and then each character will add its own details. Although not necessarily a complex modification (if the abstractions of the Character and his heirs are good).
A new class of characters - here you need to describe the combination of skills, how to coordinate them with each other. Code as in a character subclass, it is possible to select individual skill subclasses adapted for a new character.
It is more difficult for an existing one to add something else, since you need the internal code of the existing iterate again. And it may be easier to inherit a descendant.
For example, the Duck suits us all, only he does not know how to shoot. So, this functionality should be imposed, it may be more convenient to add 2 classes at once: Simple Duck and Duck, who can shoot. And in the Duck class, leave common responsibility for the daughter ducks - the ability to swim - adapted to the duck: in the form of swimming and diving.
Another side of the difficulty is to add a new responsibility (class). There is a need to correlate it with all existing ones. Potentially, this process can go to infinity, and the more existing classes, the longer it will be. The help in this is design from top to bottom: there is a world, it creates characters and allows them to interact by means of skills. Characters skills can gain / lose.
From this position, mixin seems to be an undefined class. It was left undefined due to the desire to make faster and not to rebuild the existing hierarchy of classes and their composition.
Source: https://habr.com/ru/post/244257/
All Articles