Est-ce que ça va d'hériter d'une classe sans rien ajouter à l'enfant, à respecter le principe ouvert ouvert?
Pour clarifier la question, voici mon contexte (ou quelque chose de très similaire).
J'ai une interface que j'appelle IDataSource. Les classes de mise en œuvre contiennent des informations pour récupérer des données. J'ai donc plusieurs classes de la mise en œuvre, disons FileSource, DatabaseSource et WebServiceSource. Jusqu'ici tout va bien.
Désormais, en fonction de la version du programme, je disposerai d'un certain traitement sur les données de ces sources, comme le décrypter, la lecture des premiers octets (signature) et tout ce que vous pouvez imaginer.
Ce que je voulais faire était d'avoir une classe de coordination, qui prendra des objets IDataSource, vérifiez leur type réel (FileSource et telle) et effectuez le traitement de données approprié avant de faire des choses avec les données finales.
[.____] Par exemple, j'aurais un FileSource qui ne nécessite aucun traitement, et un EncryptedFileSource qui nécessite un déchiffrement, mais les classes elles-mêmes sont complètement équivalentes ( mêmes propriétés) dans un vide.
Donc, la question devient, est-ce que ça va d'avoir EncryptedFileSource hériter FileSource, qui implémente IDataSource, et dans ma classe de coordination, vérifiez si le IDataSource Type d'objet est FileSource ou EncryptedFileSource et effectuez le déchiffrement dans le second cas?
Ou y a-t-il une meilleure façon de le faire?
Oui. Avez-vous vu combien de fois Exception a été sous-classé juste pour ajouter un nouveau type d'exception?
- Ouvrir une extension (dans ce cas, l'extension ajoute un type)
- Fermé pour la modification (dans ce cas, vous n'avez pas changé
Exceptions comportement.
Je dirais que vous allez bien dans les directives principales ouvertes.
Maintenant, si vous obtenez trop de types BSAE, vous voudrez peut-être les consolider sous "Vous n'allez pas en avoir besoin" dans moins de types de base, plus généraux. Mais c'est un principe complètement différent.