Le modèle de composition de Go peut-il encore souffrir du problème de la classe de base fragile ?

Problème de classe de base fragile dans Go : malgré la composition par rapport à l'héritage

Le problème de classe de base fragile survient lorsque des modifications apportées à une classe de base peuvent entraîner des conséquences inattendues comportement dans les classes dérivées. Ce problème est généralement attribué à l'héritage, où les classes dérivées héritent des méthodes et des champs de leurs classes de base.

Dans Go, l'héritage n'est pas implémenté. Au lieu de cela, Go utilise la composition, où une structure peut contenir des instances d'autres structures. Cependant, certains soutiennent que le problème de la classe de base fragile peut toujours exister dans Go lorsque vous travaillez avec des types intégrés.

Les types intégrés promeuvent les champs et les méthodes du type intégré vers le type wrapper. Bien que cela fournisse un accès pratique, cela élimine le polymorphisme. Cela signifie que les méthodes définies dans le type intégré ne peuvent pas être remplacées dans le type wrapper et que tout appel de méthode effectué par le type intégré invoquera toujours la définition d'origine.

En conséquence, le problème de la classe de base fragile est présent. en Go sous une forme atténuée. Les modifications apportées aux méthodes ou aux champs du type intégré peuvent affecter le type wrapper, mais uniquement si le type wrapper ne définit pas ses propres méthodes avec les mêmes noms.

Exemple

Considérez le code Java suivant, où une classe de base Counter contient une méthode d'incrémentation inc() et une méthode d'incrémentation incBy(). Une classe dérivée MyCounter remplace inc() pour appeler incBy(1).

<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>

Si la méthode incBy() de la classe de base est modifiée pour utiliser une boucle, la classe dérivée MyCounter entrera dans une boucle infinie car inc() appelle incBy() qui appelle à nouveau inc() :

<code class="java">void incBy(int n) {
    for (; n > 0; n--) { inc(); }
}</code>

Dans Go, le même exemple ne présente pas ce problème car Go ne prend pas en charge les méthodes de substitution dans les types intégrés :

<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>

Même si la méthode IncBy() du type Counter est modifiée pour utiliser une boucle, le type MyCounter n'hérite pas de ce comportement car il ne définit pas de méthode nommée Inc(). Au lieu de cela, il appelle la méthode inc() d'origine définie dans le type Counter.

Par conséquent, le problème de classe de base fragile n'est pas une préoccupation majeure dans Go en raison du manque de polymorphisme dans les types intégrés, ce qui empêche un comportement inattendu. lors de la modification des types intégrés.

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!