L'approche d'intégration de Go élimine-t-elle le problème de la classe de base fragile ?

Problème de classe de base fragile dans Go : une différence subtile

Malgré l'adoption de la composition plutôt que de l'héritage comme principe de conception, la question persiste : est-ce que la Un problème de classe de base fragile existe-t-il dans Go ?

Définir le problème de la classe de base fragile

Le problème de la classe de base fragile se pose lorsqu'un changement dans la classe de base affecte ses classes dérivées dans manières involontaires. Cela se produit en raison du polymorphisme, dans lequel les méthodes des classes dérivées peuvent remplacer celles de la classe de base. Si la méthode de la classe de base est ensuite modifiée, elle peut involontairement interrompre le comportement des classes dérivées.

Point de vue de Go sur le problème

Dans Go, le polymorphisme est absent en raison au manque de méthodes virtuelles. Au lieu de cela, Go utilise l'intégration, où une structure peut contenir une autre structure et accéder directement à ses méthodes. Bien que cette approche élimine l'impact direct du problème de la classe de base fragile, elle introduit une nuance subtile.

Intégration et promotion de méthodes

Lorsqu'une structure est intégrée, toutes ses les méthodes sont promues dans la structure englobante. Cependant, ces méthodes ne peuvent pas être remplacées dans la structure englobante. Au lieu de cela, de nouvelles méthodes portant le même nom peuvent être ajoutées, mais l'appel de la méthode promue à partir de la structure intégrée invoquera toujours la définition d'origine.

Un exemple en contexte

Considérons l'exemple Java suivant qui illustre le problème de la classe de base fragile :

<code class="java">class Counter {
    int value;
    void inc() { value++; }
    void incBy(int n) { value += n; }
}
class MyCounter extends Counter {
    @Override
    void inc() { incBy(1); }
}</code>

Ici, modifier Counter.incBy() pour itérer et appeler inc() casserait MyCounter.inc(), conduisant à un boucle infinie.

En Go, cependant, un exemple similaire n'entraînerait pas une telle rupture en raison du manque de polymorphisme. Les méthodes Counter intégrées ne peuvent pas être remplacées, donc la méthode Counter.Inc() d'origine serait toujours invoquée, quel que soit le contexte d'appel.

<code class="go">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) }</code>

Dans ce cas, la modification de Counter.IncBy() n'affecterait pas MyCounter.Inc(), qui continuerait à incrémenter le compteur de 1.

Conclusion

While Go atténue le problème de classe de base fragile en raison de l'absence de méthodes virtuelles , cela ne l’élimine pas entièrement. La valorisation des méthodes lors de l’encastrement introduit une forme nuancée de la problématique. Cependant, cette nuance est moins perturbatrice et plus prévisible par rapport au problème classique de la classe de base fragile.

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!