Tonight our best friend Skep woke up from sleep due to a terrible nightmare. The dream was the worst: a giant question mark and more Skep ran after him stronger than the demon approached. Eventually our friend was reached and the question mark, with a threatening tone, to put a difficult question: what is the difference between inheritance and subtyping ? course, the dream was not the most dramatic Perun normal person, but for a nerd like programming Skep this question is almost frightening. You want to enter as we called them or with their Italian translation, or inheritance and subtyping, these two cornerstones of object-oriented programming are often, at least in the common language of programmers, or at least as used interchangeably interchanged without creating an international scandal. If your language is Java reference, this is absolutely wrong because strettamenete these two concepts are related to each other. Even in C + + the situation is similar, although as we shall see there is an "escape route" that allows you to analyze them separately. In any case, as surely you know, we never stop us Sickdevelopers appearances and we want to understand why, for a concept that would seem similar, we use two different terms.
reasons just outside of any specific programming language. According to the theory of languages, the two terms have a very different meaning, which is now summed up in these definitions:
- Inheritance (Inheritance) : the ability to reuse the definition of an object to define a new type.
- Subtyping (subtyping) : object B is a subtype of an object A if and only if it is required whenever an object of type A can use an object of tipo B senza causare un errore di tipo.
L'ereditarietà è un concetto strettamente legato al riuso del codice già scritto per creare nuovi tipi e alla facilità di manutenzione, in quanto cambiamenti a codice condiviso da più tipi comportano la modifica di una sola porzione di programma scritto. L'ereditarietà è fondamentalmente "inutile" da un punto di vista teorico ma drammaticamente indispensabile da un punto di vista pratico: potremmo pensare di eliminare questo concetto semplicemente duplicating the shared code in the definition of any kind. It 'clear that a significant change to the code would be impractical on a large scale since it involves the modification of each portion duplicated.
The subtyping relation is the relationship that binds two types of relationship defined in : it binds the two classes which are inseparably so that, as mentioned, a subject of "child" can be used instead of "father" every as needed his father. That 's what makes the polymorphism in object-oriented programming languages \u200b\u200bwith dynamic lookup. Theoretically it is not necessary classes father and son share the same code, rather it is important to the ability exchange between father and son (clearly in one direction).
We have seen the meanings of two terms, which are very different. But why then they are often misunderstood and used in a similar way? The answer is simple: in modern programming languages \u200b\u200bpossimo, as mentioned above, consider substantially united in one idea. This union is a design choice Motl important, certainly along with other equally impoertanti, decreed the planetary success of languages \u200b\u200blike Java and C + + before then. Let's analyze them one by one, starting with the latter.
Minestrone Java
Once the vegetables and mince them together is impossible to separate the boil and eat them separately. Similarly, in the language of today's most popular , inheritance and subtyping are inseparably linked. When we extend a base class, its subtype must share the code already written, inheriting the data fields and methods, with the possibility of redefinition. So, why you should absolutely be no subtyping inheritance. It 'also applies to the contract, as to reuse code written for the adoption of methods of an object you must define a subtype, otherwise you should completely rewrite the functions. The two concepts are absolutely inseparable, theoretically questionable choice but practically very efficient in 99.9% of cases (sickStatistica completely random, empirical [ask for the exact data Skep]).
Pizza C + +
In Pizzeria, a pizza is ordered default port with the tomato. To everyone, good or bad, like pizza with tomatoes, but some people may be allergic or even might not like their tomato (sacrilegio!!). Suppose the pizza dough as subtyping and inheritance as the tomato: it is clear to most that the two things go hand in hand, but some might not be pleasant even harmful! What I am trying to say with this example is that culinary C + + allows subtyping without inheritance, anceh though to a lesser extent. The decision to Bjarne Stroustrup was to merge the two concepts into one (with good results), but to keep a door open for a separation. There is in fact private inheritance that causes an object to be subtype B, without an object can be accessed from outside to the methods inherited from B, making the idea of \u200b\u200bpartiality of separation. In short, in a world written in Java, some do not eat the pizza. There
Inguaggiato that separate the two concepts in a close, an all Smalltalk, on which I could not honestly say anything interesting.
Skep can now go back to sleep soundly, at least until the next nightmare ...
Before I go I want to throw a little challenge: someone would be able to give me an example of good sense and possibly private inheritance?
0 comments:
Post a Comment