En Java, je définis une classe abstraite avec des méthodes concrètes et abstraites, et elle doit être sous-classée de manière indépendante par des développeurs tiers. Juste pour être sûr: Y a-t-il des changements que je pourrais apporter à la classe abstraite qui sont compatibles avec leurs classes mais non compatibles binaires? En d'autres termes: après avoir compilé leurs sous-classes, puis-je changer la classe abstraite - à part par exemple. Ajout d'une méthode abstraite à elle ou enlever une méthode protégée qui s'appelle par des sous-classes, qui sont bien entendu une source incompatible - de manière à pouvoir les forcer à recompiler leurs sous-classes?
3 Réponses :
Bien sûr.
Vous pouvez utiliser accidentellement un nom de méthode qu'ils ont utilisé, qui est maintenant soudainement remplacé, avec peut-être des résultats de façon dramatique différents.
Vous pouvez ajouter des champs à la classe qui gâchent la sérialisation etc.
S'il n'est pas trop tard pour changer votre système, je vous suggère de le faire. Le dépassement n'est généralement pas un bon moyen de personnaliser la fonctionnalité, car il est incroyablement fragile. Par exemple, si vous utilisez ultérieurement un nom de méthode que vos clients ont utilisé (qu'ils prennent désormais automatiquement involontairement), il est possible que le remplacement de la substitution brise complètement les invariants de votre classe. Une manière généralement meilleure de fournir une personnalisation consiste à donner à vos clients une interface limitée uniquement au comportement personnalisé, puis vous avez une classe entièrement concrète qui dépend d'une instance de cette interface et des délégués de manière appropriée à l'interface lorsqu'il doit Utilisez les comportements personnalisés. De cette façon, votre code et le code de votre client sont complètement séparés et ils n'interfèrent pas les uns avec les autres.
Merci d'avoir également fourni l'alternative! C'était aussi ce que j'avais envisagé - je pesais ses coûts dans la complexité (en maintenant une référence à la mise en œuvre et de la déléguer) mais que cette architecture enfichable est une exigence, je vais le faire.
Je suppose que vous utilisez "Incompatibilité binaire" dans le sens technique; par exemple. où le chargeur de classe détecte l'incompatibilité et refuse de charger les classes.
Une incompatibilité binaire pourrait également être introduite si vous avez ajouté une méthode visible De même, l'ajout de nouveaux champs visibles entraînera la dissimulation, peut entraîner un comportement déroutant et briser la sérialisation de l'objet. Mais cela n'entraînera pas une incompatibilité binaire.
En général, cela indique le fait que vous devez envisager des problèmes sémantiques d'application ainsi qu'une simple compatibilité binaire. Et le système de type Java ne vous aidera pas là-bas.
En complétude, vous pouvez faire une autre chose que vous pourriez faire dans votre code qui briserait la compatibilité binaire des classes 3ème partie:
finale , et cette méthode est entrée en collision avec la signature d'une méthode existante dans une tierce partie Sous-classe. Toutefois, si la méthode n'est pas finale, la méthode existante se transformera en une substitution de votre (nouveau) méthode pouvant causer des problèmes ... mais pas une incompatibilité binaire.
Merci de la réponse complète et de penser à ce que j'ai aussi pensé, mais n'a pas décrit, à savoir d'autres moyens de casser le code des implémentations.
Bonne réponse. Les règles de compatibilité binaire et source sont très indépendantes les unes des autres. Il est important de les comprendre à la fois séparément. Motlin.com/2010/binary-et-source-backwards-compatibilité