Quali sono i pro e i contro dell'ereditarietà multipla? [chiuso]

4

Quali sono le conseguenze di consentire l'ereditarietà multipla in un linguaggio di programmazione?

Quali caratteristiche dell'ereditarietà multipla creano un ambiente tale che l'uso dell'ereditarietà multipla tende a generare codice sorgente che viola uno o più principi di programmazione orientata agli oggetti e ingegneria del software di qualità?

In che modo la mancanza di ereditarietà multipla in Java e in altri linguaggi OOP che non consentono l'ereditarietà multipla offre l'opportunità di una migliore qualità del software rispetto a un linguaggio che consente l'ereditarietà multipla come C ++?

Spiega e illustra.

    
posta Maxood 30.11.2011 - 10:48
fonte

2 risposte

7

La principale conseguenza dell'ereditarietà multipla è il problema dei diamanti :

In object-oriented programming languages with multiple inheritance and knowledge organization, the diamond problem is an ambiguity that arises when two classes B and C inherit from A, and class D inherits from both B and C. If a method in D calls a method defined in A (and does not override the method), and B and C have overridden that method differently, then from which class does it inherit: B, or C?

In C ++ il problema è risolvibile tramite eredità virtuale :

This feature is most useful for multiple inheritance, as it causes that subobject of the virtual base will be always a common subobject for all classes that are derived in the deriving class (as well as this class itself). This can be used to avoid the problem of ambiguous hierarchy composition (known as the "diamond problem") by clarifying ambiguity over which ancestor class to use, as from the perspective of the deriving class (B in the example above) the virtual base (V) looks as if it was its direct base class, not a class being derived indirectly through its bases (A).

I linguaggi OOP del sapore ereditario singolo forniscono un certo grado di ereditarietà multipla per ereditarietà di interfacce e / o tramite tratti / mixins (concetti simili). Il problema del rombo si verifica anche in quelle lingue e viene trattato principalmente con tecniche specifiche della lingua.

Ora che Java è un "linguaggio OOP puro", è più un discorso di marketing di Sun (e fanboys di Java parlano) che di verità. Ho visto la "purezza di OOP" misurata dal grado in cui una lingua fornisce / soddisfa i seguenti criteri:

Seguendo questa "logica", Java supporta tipi di dati primitivi come int e byte, quindi meno puri di quanto si possa dire Smalltalk , dove tutto è veramente un oggetto. Ma misurare la "purezza" di qualsiasi caratteristica di una lingua non ha valore reale, è un tipo di discussione giovanile "mio è meglio del tuo".

Aggiornamento:

Ho trovato questa domanda molto interessante su StackOverflow: In che modo Ruby è più orientato agli oggetti di Python? :

Matz, who invented Ruby, said that he designed the language to be more object-oriented than Python. How is Ruby more object-oriented than Python?

La risposta più votata offre alcuni spunti interessanti:

If you take the Python from 1993 and compare it with Ruby then the later is more object oriented. However, after the overhaul in Python 2.2 this is no longer true. I would say that modern Python is as object oriented as it gets.

Ho visto spesso i cultisti di Ruby iniziare guerre sante basate sui commenti di Matz sul progetto iniziale di Ruby. Come la risposta che faccio riferimento dice: non si dovrebbe ignorare il contesto storico. Qualcosa che potrebbe essere stato vero nel 1993, non deve necessariamente essere vero ora. Lo stesso dicasi per i cultisti del C ++ che fanno riferimento a Bjarne Stroustrup fuori dal contesto, i cultisti Java che fanno riferimento a James Gosling fuori dal contesto e così via.

Per aggiungere confusione, la parola "puro" ha connotazioni prevalentemente positive :

  1. free from anything of a different, inferior, or contaminating kind; free from extraneous matter: pure gold; pure water.
  2. unmodified by an admixture; simple or homogeneous.
  3. of unmixed descent or ancestry: a pure breed of dog.
  4. free from foreign or inappropriate elements: pure Attic Greek.
  5. clear; free from blemishes: pure skin.

Ma nel contesto dei linguaggi di programmazione, significa solo omogeneo :

  1. composed of parts or elements that are all of the same kind; not heterogeneous: a homogeneous population.
  2. of the same kind or nature; essentially alike.
  3. Mathematics.
    1. having a common property throughout: a homogeneous solid figure.
    2. having all terms of the same degree: a homogeneous equation.
    3. relating to a function of several variables that becomes multiplied by some power of a constant when each variable is multiplied by that constant: x 2 y 3 is a homogeneous expression of degree 5.
    4. relating to a differential equation in which a linear combination of derivatives is set equal to zero.

Detto questo, c'è solo un linguaggio di programmazione veramente puro .

    
risposta data 30.11.2011 - 10:59
fonte
2

Wikipedia ha una sezione sulle critiche per l'ereditarietà multipla, che è un buon punto di partenza come qualsiasi. Solo per riferimento, ecco i punti principali:

  • ambiguità semantica
  • non puoi ereditare più volte da una singola classe
  • l'ordine di ereditarietà cambia la semantica

Ma ancora più importante, dovresti stare attento quando parli della essenza di OOP e di linguaggi come C ++ e Java. Nessuno di questi è un puro linguaggio OOP. Dai un'occhiata a linguaggi come Smalltalk per il confronto.

Un'altra tendenza recente sono i mixin (C #) o i tratti (Scala), che hanno rianimato l'ereditarietà multipla in un modo che tenta di eliminare le critiche di cui sopra ad un certo punto.

Questa non è una risposta completa, che è intenzionale, poiché dalle tue domande percepisco una mancanza di conoscenza fondamentale (più la domanda è potenzialmente compito a casa). Così, invece, ho garantito di fornirti indicazioni su dove andare per saperne di più su questo.

    
risposta data 30.11.2011 - 11:06
fonte

Leggi altre domande sui tag