Dois-je recommander les cours de scellement par défaut ?

Question

Dans un grand projet pour lequel je travaille, j'envisage de recommander aux autres programmeurs de toujours sceller leurs classes s'ils n'ont pas réfléchi à la manière dont leurs classes doivent être sous-classées. Souvent, les programmeurs moins expérimentés n'y pensent jamais.

Je trouve étrange qu'en Java et en C# les classes soient non scellées / non finales par défaut. Je pense que rendre les classes scellées améliore grandement la lisibilité du code.

Remarquez qu'il s'agit d'un code interne que nous pouvons toujours modifier dans le cas, rare, où nous devons créer une sous-classe.

Quelles sont vos expériences ? Je rencontre une certaine résistance à cette idée. Les gens sont-ils si paresseux qu'ils ne prennent pas la peine de taper sealed ?

Answer 1

Ok, comme tant d'autres personnes ont pesé dans la balance...

Oui, je pense qu'il est tout à fait raisonnable de recommander que les classes soient scellées par défaut.

Cela va dans le sens de la recommandation de Josh Bloch dans son excellent livre Java efficace, 2e édition :

Concevoir pour l'héritage, ou l'interdire.

Concevoir pour l'héritage, c'est dur et peut faire votre mise en œuvre moins flexible, surtout si vous avez des méthodes virtuelles, dont l'une appelle l'autre. Ce sont peut-être des surcharges, peut-être pas. Le fait que l'une appelle l'autre doit être documenté Sinon, vous ne pouvez pas surcharger l'une ou l'autre méthode en toute sécurité - vous ne savez pas quand elle sera appelée, ni si vous pouvez appeler l'autre méthode sans risquer un débordement de pile.

Si, par la suite, vous voulez changer quelle méthode appelle quelle autre dans une version ultérieure, vous ne pouvez pas le faire, car vous risqueriez de casser les sous-classes. Donc, au nom de la "flexibilité", vous avez en fait fait l'implémentation moins flexible, et que vous deviez documenter les détails de votre implémentation de manière plus précise. Cela ne me semble pas être une bonne idée.

Ensuite, il y a l'immuabilité - j'aime les types immuables. Je trouve qu'il est plus facile de raisonner sur eux que sur les types mutables. C'est une des raisons pour lesquelles le Joda Time est plus agréable que l'utilisation de l'API Date y Calendar en Java. Mais une classe non scellée ne peut jamais être connu sous le nom de pour être immuable. Si j'accepte un paramètre de type Foo je pourrai peut-être compter sur les propriétés déclaré dans Foo de ne pas être modifié au fil du temps, mais je ne peux pas compter sur le fait que l'objet lui-même ne soit pas modifié - il pourrait y avoir une propriété mutable dans la sous-classe. Que le ciel me vienne en aide si cette propriété est également utilisée par une surcharge d'une méthode virtuelle. Dites adieu à bon nombre des avantages de l'immuabilité. (Ironiquement, Joda Time a de très grandes hiérarchies d'héritage - souvent avec des choses disant "les sous-classes doivent être immuables". La grande hiérarchie d'héritage de Chronology le rendait difficile à comprendre lors du portage en C#).

Enfin, il y a l'aspect de la surutilisation de l'héritage. Personnellement, je préfère la composition à l'héritage lorsque c'est possible. J'adore le polymorphisme pour les interfaces, et le occasionnellement J'utilise l'héritage de l'implémentation - mais c'est rarement un bon ajustement dans mon expérience. Rendre les classes scellées évite qu'elles soient inapproprié dérivé d'où la composition serait mieux adaptée.

EDIT : J'aimerais également indiquer aux lecteurs les sites suivants Article du blog d'Eric Lippert datant de 2004 sur la raison pour laquelle tant de classes du cadre sont scellées. Il y a beaucoup d'endroits où j'aurais aimé que .NET fournisse une fonction interface nous pourrions travailler à la testabilité, mais c'est une demande légèrement différente...

Answer 2

Je pense que les décisions de conception architecturale sont prises pour communiquer aux autres développeurs (y compris les futurs développeurs de maintenance) quelque chose d'important.

Le scellement des classes indique que l'implémentation ne doit pas être surchargée. Elle indique que la classe ne doit pas être usurpée. Il y a de bonnes raisons de sceller.

Si vous adoptez l'approche inhabituelle consistant à tout sceller (et c'est inhabituel), vos décisions de conception communiquent alors des choses qui ne sont pas vraiment importantes, comme le fait que la classe n'a pas été prévu pour être hérité par le développeur original/auteur.

Mais alors comment communiquer aux autres développeurs que la classe devrait ne peut être hérité à cause de quelque chose ? Tu ne peux vraiment pas. Vous êtes coincé.

De plus, sceller une classe n'améliore pas la lisibilité. Je ne le vois pas. Si l'héritage est un problème dans le développement de la POO, alors nous avons un problème beaucoup plus grand.

Answer 3

J'aime à penser que je suis un programmeur raisonnablement expérimenté et, si je n'ai rien appris d'autre, c'est que je suis remarquablement mauvais pour prédire l'avenir.

La saisie scellée n'est pas difficile, mais je ne veux pas irriter un développeur (qui pourrait être moi !) qui découvrirait qu'un problème pourrait être facilement résolu avec un peu d'héritage.

Je ne vois pas non plus comment le fait de sceller une classe la rend plus lisible. Essayez-vous de forcer les gens à préférer la composition à l'héritage ?

Answer 4

Il n'y a rien de mal à hériter d'une classe.

Vous ne devriez sceller une classe que lorsqu'il y a une bonne raison pour laquelle elle ne devrait jamais être héritée.

De plus, si vous les scellez tous, cela ne fera que diminuer la maintenabilité. Chaque fois que quelqu'un voudra hériter de l'une de vos classes, il verra qu'elle est scellée, puis il enlèvera le sceau (en manipulant du code qu'il ne devrait pas avoir à manipuler) ou pire : il créera une mauvaise implémentation de votre classe pour lui-même.

Vous aurez alors deux implémentations de la même chose, l'une probablement pire que l'autre, et deux morceaux de code à maintenir.

Il vaut mieux le garder non scellé. Il n'y a pas de mal à ce qu'il soit descellé.

Answer 5

Franchement, je pense que le fait que les classes ne soient pas scellées par défaut en C# est un peu bizarre et déplacé par rapport à la façon dont le reste des défauts fonctionnent dans le langage.

Par défaut, les classes sont internal . Par défaut, les champs sont private . Par défaut, les membres sont private .

Il semble qu'une tendance se dessine en faveur de l'accès le moins plausible par défaut. Il serait logique qu'un unsealed doit sortir en c# au lieu d'un mot-clé sealed .

Personnellement, je préférerais que les classes soient scellées par défaut. Dans la plupart des cas, lorsque quelqu'un écrit une classe, il ne la conçoit pas en pensant aux sous-classes et à toutes les complexités qui en découlent. La conception d'une future sous-classe devrait être un acte conscient et donc je préférerais que vous ayez à le déclarer explicitement.