Hériter d'une classe ou d'une classe abstraite

Si la classe de base ne devrait pas être instanciée, puis en faire une classe abstraite - si la classe de base doit être instancié alors ne pas en faire abstraction.

Dans cet exemple, il est logique de faire de la classe de base abstraite comme la classe de base n'a pas de sens concret:

abstract class WritingImplement
{
    public abstract void Write();
}

class Pencil : WritingImplement
{
    public override void Write() { }
}

Cependant, dans l'exemple suivant, vous pouvez voir comment la classe de base n'ont un sens concret:

class Dog
{
    public virtual void Bark() { }
}

class GoldenRetriever : Dog
{
    public override void Bark() { }
}

C'est très subjectif vraiment, vous devriez être en mesure de faire un assez bon jugement d'appel, sur la base des besoins de votre domaine particulier.

Je suggère:

• Faire une interface.
• Implémenter l'interface de votre classe de base.
• Faire de la classe de base d'une véritable classe, non pas abstraite (voir ci-dessous pourquoi).

La raison, je préfère le réel classes au lieu de classes abstraites, c'est que les classes abstraites ne peut pas être instanciée, ce qui limite les options pour l'avenir inutilement. Par exemple, plus tard, j'ai peut-être besoin de l'état et des méthodes de la classe de base, mais ne peut pas hériter et n'ont pas besoin d'implémenter l'interface; si la classe de base abstraite, je suis hors de la chance, mais si la classe de base est une classe ordinaire alors je peux créer une instance de la classe de base et tenez-le comme une composante de mon autre classe, et délégué à l'exemple de réutilisation de l'état/méthodes prévues.

Oui cela n'arrive pas souvent, mais le point est: faire de la classe de base abstraite empêche ce genre de réutilisation/solution quand il n'y a aucune raison de le faire.

Maintenant, si l'instanciation de la classe de base serait en quelque sorte dangereux, puis de la rendre abstraite - ou, de préférence, de le rendre moins dangereux, si possible 😉

Les classes abstraites sont partiellement mises en œuvre classes.

Par lui-même n'a pas de sens d'avoir une instance d'une classe abstraite, elle doit être dérivée. Si vous souhaitez être en mesure de créer de la classe de base, il ne peut pas être abstraite.

J'aime à penser que les classes abstraites interfaces qui ont certains membres de la pré-définis, car ils sont communs à tous les sous-classes.

Je dirais que si vous envisagez de ne pas l'appeler la classe de base par lui-même, alors vous devez le définir comme une classe abstraite.

Les classes abstraites sont grands pour les prédéfinis fonctionnalités, par exemple - sais quand le minimum exacte le comportement d'une classe doit exposer, mais pas de quelles données il doit utiliser et, ou, l'exacte mise en œuvre.

abstract class ADataAccess
{
    abstract public void Save();
}

Normal (non abrégé) classes peut être grande pour des choses similaires mais vous devez savoir que la mise en œuvre de détails pour être en mesure de les écrire.

public class DataAccess
{
    public void Save()
    {
        if ( _is_new )
        {
            Insert();
        }
        else if ( _is_modified )
        {
            Update();
        }
    }
}

Aussi, vous pouvez utiliser les interfaces (individuellement ou sur des classes, que ce soit abstrait ou pas) pour définir le genre même de la définition du prototype.

interface ISaveable
{
    void Save();
    void Insert();
    void Update();
}

class UserAccount : ISavable
{
    void ISavable.Save() { ... }
    void ISavable.Insert() { ... }
    void ISavable.Update() { ... }
}

Encore une autre option pourrait être l'utilisation de génériques

class GenDataAccess<T>
{
    public void Save()
    {
        ...
    }
}

Toutes ces méthodes peuvent être utilisées pour définir un certain prototype pour les classes de travailler avec. Manières de s'assurer qu'Un code peut parler de code B. Et bien sûr, vous pouvez mélanger et assortir tous les ci-dessus à votre convenance. Il n'existe pas de bonne façon mais j'aime bien la définition d'interfaces et les classes abstraites, puis se référant aux interfaces. De cette façon, élimine certaines de la pensée exigences de "plomberie" dans les classes de niveau supérieur, tout en conservant le maximum de flexibilité. (le fait d'avoir des interfaces enlève l'exigence de l'utilisation de la classe de base abstraite, mais qui la laisse comme une option).