Ma compréhension de l'utilisation de la classe abstraite ou de l'interface

Question

Je souhaite valider ma compréhension de quand et pourquoi utiliser un résumé ou une interface.

Mon exemple concerne les humains. Un humain peut être un homme ou une femme. Un humain peut avoir une profession différente dans la vie. Donc, comment je les utilise:

Je vais déclarer les professions comme Interface, car il établira un contrat de ce qu'un humain peut faire dans cette profession. Exemple:

Interface SoftwareEngineer{ 
code(); 
} 

Interface TruckDriver{ 
driveTruck(); 
} 

Interface Pilot{ 
flyPlane(); 
} 

Et je déclare l'homme et la femme comme classe- abstraite parce que l'homme et la femme sera la personne qui est.

Abstract Man{ 

} 

Abstract Woman{ 

} 

L'utilisation de la classe pour définir une personne peut implémenter l'interface profession pour définir ce que la personne peut faire et la personne étendre la classe abstraite pour définir qui il/elle est.

Class Mark extends Man, Implements SoftwareEngineer{ 

    code(){ 

    } 
} 

Ce que je voudrais expliquer quelqu'un au sujet de l'interface et de la différence abstraite de ma compréhension. Mais je me demande comment répondre à deux questions ci-dessous:

1. Vous ne pouvez pas instancier une classe abstraite, alors si vous faites l'homme et la femme comme abstraite comment pouvez-vous instancier ces classes. Comment peut-il être utile? Pourquoi avez-vous fait l'homme et la femme abstraite, pourquoi ne pouvez-vous pas simplement les faire comme une interface. La classe les implémentera au lieu de l'étendre.

Telles sont les questions que je me pose. Je pourrais manquer quelque chose ici. Appréciez les idées dans cet exemple.

Answer 1

Je voudrais citer un commentaire de ce lien: What's the difference between an abstract class and an interface?

classes définissent ce qu'est une chose, les interfaces définissent ce que quelque chose peut faire

Gardant ce concept à l'esprit, l'homme et la femme définissent ce qu'est une personne. Considérant qu'un Profession est juste une caractéristique d'une personne, neutre envers le genre. C'est la raison pour l'avoir comme interface.

maintenant à vos questions:

1. Vous ne pouvez pas instancier une classe abstraite, alors si vous faites l'homme et la femme comme abstraite comment pouvez-vous instancier ces classes. Comment peut-il être utile?

Ces classes abstraites seront utiles si vous créez un nouvel homme, dit Sam. Sam va avoir des comportements différents. Par conséquent, en ayant une classe abstraite 'Man', vous pouvez ajouter plus de détails à Sam, tout en conservant les détails de base minimum requis pour un 'Homme'. En fait, par définition des classes abstraites, vous pourriez avoir une fonctionnalité par défaut implémentée pour certaines de ses fonctions (Man), que vous pouvez remplacer pour la classe dérivée (Sam). Notez, Interfaces ne peut pas avoir de fonctionnalité du tout, tout ce qu'ils définissent est juste structure. Et je vous suggère de penser à l'humain comme une classe abstraite.

2. Pourquoi avez-vous rendu l'homme et la femme abstraits, pourquoi ne pouvez-vous pas simplement en faire une interface? La classe les implémentera au lieu de s'étendre? Tout simplement parce qu'un homme ou une femme n'est pas seulement une caractéristique, mais il va définir une grande partie de la composition dans les classes dérivées. Deuxièmement, étant donné que les interfaces sont particulièrement axées sur les caractéristiques, les langues permettent l'héritage multiple à partir des interfaces. Alors qu'une personne ne peut pas être homme et femme en même temps.En résumé, vous définissez une classe abstraite chaque fois que votre intention est de couvrir en grande partie tous les aspects de la classe dérivée. Et interfaces pour les caractéristiques qui pourraient être partagées par de nombreux types différents. Par exemple, une interface IRead pour tous les objets pouvant être lus. Maintenant, la lecture n'est pas seulement applicable à l'homme ou à la femme, elle pourrait aussi s'étendre aux gadgets.

Answer 2

Cette mallette est généralement conforme au modèle de conception Startegy. (avec Suggestion d'avoir une classe de base abstraite commune pour les sous-classes abstraites Homme/Femme). N'utilisez jamais de classe de base en béton.

Dans votre exemple SoftwareEngineer (le nom de la classe ne peut pas être Mark car il peut être l'objet de cette classe) ne peut jamais devenir professeur lors de l'exécution. En réalité, Mark peut devenir, non?

modèle de stratégie avec prise en charge d'une profession à la fois (pour plusieurs professions en même temps, nous devrons modifier modèle Impl) utilisera la classe humaine (M/W) en tant que contexte et professeur/SoftwareEngineer comme des stratégies concrètes en général . Le problème ne s'arrête pas là, il va générer de nouveaux défis sur les différents revenus dus aux différentes professions car il va demander un changement d'état. Mais le problème peut être résolu en utilisant la stratégie comme modèle de base.

Answer 3

Une interface est un contrat avec le monde extérieur, votre meilleur face avant. D'une certaine manière, cela vous permet également d'implémenter plusieurs héritages en Java.

Une abstraite classe est là pour fournir un ensemble de fonctionnalités communes qui peuvent être partagées par toutes ses sous-classes, par exemple, les attributs, les champs, etc.

Maintenant, nous allons passer en revue les exemples que vous avez fournis dans votre message.

1. Homme et Femmen'a pas besoin d'être des classes abstraites si une instance d'un homme ou une femme peut exister sans une profession. Ainsi, ils peuvent être des classes concrètes.
2. Vous ne voulez pas non plus Man ou Femme pour être une interface. Cela évitera à une classe d'implémenter à la fois les interfaces Man et Woman.
3. En étant des classes abstraites, Man et Femme Les classes peuvent fournir un ensemble commun de fonctionnalités.
4. Une classe nommée Mark n'est pas un nom approprié pour une classe concrète qui étend Man et met en œuvre SoftwareEngineer. Peut être ManSoftwareEngineer est un meilleur nom (je sais que c'est subjectif). Cependant, Mark est un bon nom pour une instance de ManSoftwareEngineer