Quand déplacer un champ commun dans une classe de base?

J'ai actuellement deux classes dérivées, Aet B, qui ont toutes deux un champ en commun et j'essaie de déterminer s'il doit remonter dans la classe de base.

Elle n'est jamais référencée à partir de la classe de base, et dire si à un moment donné, une autre classe est dérivée, Cqui n'a pas de _field1, alors le principe des "moins privilégiés" (ou quelque chose) ne serait-il pas violé s'il était?

public abstract class Base
{
    // Should _field1 be brought up to Base?
    //protected int Field1 { get; set; }
}

public class A : Base
{
    private int _field1;
}

public class B : Base
{
    private int _field1;
}

public class C : Base
{
    // Doesn't have/reference _field1
}

Tout dépend du problème exact que vous essayez de résoudre.

Prenons un exemple concret: votre classe de base abstraite est Vehicleet vous avez actuellement les implémentations concrètes Bicycleet Car. Vous envisagez de passer numberOfWheelsde Bicycleet Carau véhicule. Devriez-vous faire ça? Non! Parce que tous les véhicules n'ont pas de roues. Vous pouvez déjà dire que si vous essayez d'ajouter une Boatclasse, cela va se casser.

Maintenant, si votre classe de base abstraite l'était, WheeledVehicleil est logique d'avoir la numberOfWheelsvariable membre dedans.

Vous devez appliquer la même logique à votre problème, car comme vous pouvez le voir, ce n'est pas une simple réponse oui ou non.

Logiquement, au-delà de placer le champ répliqué dans des sous-classes vs en commun dans la classe de base, il y a une troisième option: introduire une nouvelle sous-classe dans la hiérarchie qui a les propriétés communes entre les deux. @Pete y fait allusion sans y aller complètement.

En utilisant l'exemple de @ Pete, nous introduirions une sous-classe (éventuellement abstraite) pour les véhicules à roues qui descend de la classe de base d'origine - tandis que les deux sous-classes en descendent. Ainsi, la classe de base d'origine n'est pas polluée par les roues, mais le point commun des roues est SEC (non répété parmi les sous-classes qui ont des roues).

Bien sûr, cela peut être exagéré pour vos besoins, mais cela est pris en charge par le mécanisme de hiérarchie des classes.

Je vais jouer l'avocat du diable ici.

Pour l'instant, vous ne devriez rien faire .

Est-ce SEC? Non. Mais il vaut mieux avoir un peu de duplication qu'une abstraction prématurée dont vous ne pourrez pas facilement vous défaire plus tard. Le refactor pour déplacer une propriété vers une classe de base commune est facile. Aller dans l'autre sens ne l'est pas. Attend et regarde.

Lorsque je prends ce genre de décision, j'ai tendance à utiliser une "règle de 3": une fois que j'ai répété la même chose, par exemple à trois endroits différents, et seulement alors, je pense à le déplacer dans la chaîne. NB vous êtes seulement à 2.

En général, je le déplacerais dans la classe de base. Je ne pense pas qu'il y ait un objectif oui / non, car il y a un compromis ici - porter des champs inutilisés contre réduire la complexité.

Je préfère généralement les classes de base «lourdes» qui contiennent tout ce qui pourrait être partagé. Cela rend la sérialisation vers des fichiers plus simple car vous n'avez pas besoin de méthodes de sérialisation descendantes dans chaque classe dérivée. Mais si vous n'avez pas cela ou un problème similaire, ou peut-être devez-vous faire tout ce que vous pouvez pour réduire l'utilisation de la mémoire, ne conserver que les champs où vous en avez besoin devrait être correct.

Une classe «intermédiaire» qui présente les champs communs sera très bien si vous avez un nombre très limité de champs. Mais sachez que cette approche peut considérablement augmenter la complexité si vous avez des dizaines de champs utilisés dans différentes combinaisons, conduisant à de nombreuses classes intermédiaires introduisant chacune un ensemble spécifique de champs. Cela peut devenir un problème de maintenance.