L'approche de composition de Go élimine-t-elle complètement le problème de la classe de base fragile ?

Problème de classe de base fragile dans Go ?

Malgré l'adoption de la composition plutôt que de l'héritage, des inquiétudes ont été soulevées quant à savoir si Go est toujours confronté à la « classe de base fragile " problème. Cet article étudie ce sujet et explore des solutions potentielles au niveau du langage.

Le problème de la classe de base fragile

Dans la programmation orientée objet classique, le problème de la classe de base fragile se pose lorsqu'une modification d'une classe de base brise les sous-classes qui s'appuient sur ses méthodes. Cela se produit en raison du remplacement d'une méthode virtuelle, où l'implémentation réelle de la méthode est déterminée au moment de l'exécution.

Composition dans Go : atténue-t-elle le problème ?

Go utilise la composition à la place d'héritage, mais fournit un mécanisme d'incorporation qui inclut les méthodes du type incorporé dans le type d'incorporation. Cependant, le remplacement de méthode n’est pas pris en charge dans Go. Toutes les méthodes du type intégré sont promues et restent dans l'ensemble de méthodes du type d'intégration.

Exemption de Go : un exemple

Pour illustrer la différence entre Go et les langages confrontés le problème de la classe de base fragile, considérons l'exemple suivant :

type Counter struct {
    value int
}

func (c *Counter) Inc() {
    c.value++
}

func (c *Counter) IncBy(n int) {
    c.value += n
}

type MyCounter struct {
    Counter
}

func (m *MyCounter) Inc() {
    m.IncBy(1)
}

En Java
La prise en charge par Java de la substitution de méthode crée un potentiel de problème de classe de base fragile. Si la méthode Counter.IncBy() était modifiée en :

void incBy(int n) {
    for (; n > 0; n--) {
        inc();
    }
}

MyCounter deviendrait inutilisable en raison d'une boucle sans fin lorsque MyCounter.Inc() appelle Counter.IncBy(), ce qui entraînerait une invocation récursive.

En Go
En Go, la même modification de Counter.IncBy() n'entraîne pas le même problème. MyCounter.Inc() appelle toujours Counter.Inc(), qui à son tour appelle Counter.IncBy(), mais cela ne crée pas de boucle puisque la fonction Inc() de Counter est invoquée, pas celle de MyCounter. Counter n'a pas de référence à MyCounter, conservant ainsi son indépendance.

Conclusion

Bien que le mécanisme de composition de Go et l'absence de remplacement de méthode atténuent le problème de classe de base fragile à un niveau significatif Dans une certaine mesure, il est important de noter qu'il n'est pas entièrement éliminé.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!