Heritage in object-oriented programming

Asked

Viewed 261 times

4

I was reading that article today and I came across the following statement:

"Inheritance refers to the ability of an object to access methods and other properties of another object."

Inheritance would not be the hierarchical relationship between classes? Where they can inherit properties and methods from other classes and so pass them on to their instances (objects).

The relationship where objects access properties and methods of other objects is described in the concepts of Associating (where an object is taken as an attribute of another), Aggregation (where a parent object receives another object in one of its methods) and Composition (where an object of another class is instantiated within the class of the parent object itself), certain?

Can anyone supplement that statement?

  • 1

    Show me where you saw this

  • I believe this is not very relevant to the question, but I will add the link.

  • Yeah, because if the source is a writing dummy it’s one thing, if it’s a reliable source it’s another. And the context will also indicate if it’s not a problem of interpretation.

  • It’s written exactly as I posted in the question. :)

  • But in the question it is not written that it speaks of prototypes and where it is being used.

  • In the introduction of the article he talks about POO inheritance and not prototypes: "In OOP, inheritance refers to the ability of an object to access methods and other properties of another object."

  • Did the answer resolve what was in doubt? Do you need something else to be improved? Do you think it is possible to accept it now?

  • I’m not talking about classes, you think I am because you think this is related to classes.

  • Because it made sense to talk about classes there, which is why it needs context.

  • Anyway, thank you for the reply. :)

  • I think the subject is too comprehensive to be dealt with here, perhaps it would be interesting you seek a book on the subject, there are many good books out there.

  • 1

    In a way yes. I’m already deepening in POO in books and courses.

Show 7 more comments

1 answer

6

I’ll start by saying what I always say. Almost no one knows object orientation correctly, which includes me, but I’m making a huge effort to resolve the outstanding parts. And I’ve been wearing this for about 30 years.

Almost everyone abuses of inheritance. People think that something has hierarchical relationship when it does not have. Most of objects are compounds by other objects and are not derived from other objects. And almost 100% of the examples of inheritance in books, blogs, and other sources show inheritance in something that has no hierarchical relationship (or that has but is not real), which makes almost everyone learn wrong. And the disinformation is disseminated since people are not questioning.

In this specific case the phrase was probably said in the context of Javascript that does not have the explicit declaration of types but objects that serve as prototypes for other objects. The phrase is unfortunate because it can be interpreted differently. An object access property of another object is possible in every object that has behavior, even without inheritance relation.

The actual inheritance is the hierarchical relationship, composed of the ability of the derivative type to have all that the base type has, either in implementation (subclass) or in contracts (subtype).

So one object derived from another has the same characteristics as the base object (its prototype), it’s all in it, it doesn’t have to access another object. Inheritance is done by copying. In the new derived object you can add or even change certain characteristics (not all languages allow this). If you change the characteristics, in my conception, you end the inheritance since the son is no longer able to do everything the same as the father. In the real world the heritage would be maintained, but in the computer it becomes complicated. There are those who think that the inheritance remains.

Note that we are talking about only one object, so the word "other" no longer fits there. Another concrete object is used as a model for this object, but ends the relationship between them the moment the new is created, does not have to access anything in the other. Fully dynamic languages often do this.

In class-based languages it works the same way, only the model is a plant and not a prototype, so there is no relation to another object even at the time of its creation.

Inheritance is not about classes, this is another mistake that almost everyone makes. There is inheritance without class. Outside that point the definition of AP is more correct than the article. Class is a condition of inheritance.

This has nothing to do with Association, Aggregation, Composition. These are powerful mechanisms to compose the object, but there is no direct relationship with access, this is circumstantial.

Strictly the phrase is wrong, but you can understand why. Of course, for laypeople it is a disinformation that collaborates so that most people don’t understand what OOP is, and everything that people don’t understand, but they think they do, they often go on to deify that. And everything that is deified "cannot be contested" by her or other people. So in programming we have to study up to theology :P

Some people may disagree because there are different schools than object orientation. I spoke of the one that seems to be most used. Some people take some concepts from one school and others from another school. And even impose antagonistic concepts in their conception. And I’m talking about people who are on a professional level above.

Related: What are the concepts of cohesion and coupling? (This is more important than OO, the DRY also). See also: What is a paradigm?.

  • 2

    I would give you a fat reward for that answer but you have more than 14x my reputation :D that’s the best answer I’ve seen this month.

  • @Renan Thanks. Pity that I will not reach the Master of 250 in 2017 :( And I will not double the goal, 2018 just want to improve the quality of the people, and my answers that have not always been a wonder lately (and I need to see what was outstanding :D) . Interestingly some very interesting things I wrote passed beaten by almost everyone.

  • People get very confused about BEING something and HAVING something. You need to ask yourself this when you create classes and relationships, this object you are creating needs to BE of a certain type (inherit) or it needs to HAVE access to a certain type. Anyway as I said above I find the subject too comprehensive to deal with on this platform.

  • 1

    @Zorkind totally. In fact most people have a near zero sense of this. Even those who understand it a little better make a big mistake in the evaluation. There is much that seems to be and is not. The square and rectangle example is the most emblematic. Some cases are debatable. A square is a geometric shape or has characteristics of a geometric shape? In the real world I know easy, in computer abstraction this is a little more complicated :)

Browser other questions tagged

You are not signed in. Login or sign up in order to post.