Un exemple d'utilisation incorrecte de l'héritage et de la combinaison en Java

Je crois que la plupart des gens connaissent davantage les deux choses de "l'héritage" et de "combinaison" en Java. Cet article discutera principalement de ces deux sujets. Si j'écris quelque chose de mal, ou si c'est enfantin et l'argument n'est pas clair, tout le monde est invité à laisser un message pour me corriger.

Qu'est-ce que la "combinaison" et "l'héritage"

Supposons qu'il y ait 2 classes: A et B :

• Si la classe A extends B, nous disons que A hérite B, A est une sous-classe, et B est une classe parentale, et ce cas est l'héritage.
• S'il y a une propriété dans A avec le type B, nous disons que cette situation est une combinaison.

Dans quelles circonstances utilisez-vous

Réfléchissez à quelles circonstances considérons-nous habituellement ces deux choses? J'y ai pensé brièvement et il y a souvent les scénarios suivants:

• Code commun
• Pour montrer les «points communs» entre les choses ou simplement pour les «génériques», une classe ou interface abstract class est extraite

Après y avoir pensé, il semble qu'il n'y ait vraiment que ces deux situations, mais ces deux situations ont une relation spéciale. Par exemple, la chose du code public peut en fait être réalisée abstract class et interface abstraites (la méthode par défaut dans Java 8).

Eh bien, après avoir dit tellement de bêtises, je vais juste jeter mon point de vue. Bienvenue à:

• Si vous souhaitez simplement utiliser le code public et qu'il n'y a pas de connexion évidente entre l'utilisation de la classe ou de la méthode de ces codes publics, utilisez des combinaisons.
• Si plusieurs classes ou méthodes ont des connexions évidentes, veuillez extraire une abstract class ou une interface abstraite
• Utilisez la fonction "Attribut Héritage" avec prudence , et il est recommandé que les sous-classes reproduisent clairement les attributs requis de la classe parent. Ceci est particulièrement important, et il y aura un exemple pour illustrer les inconvénients de cette situation.

Le matériel pédagogique négatif

Un exemple plus courant: dans les projets réels, nous définissons souvent POJO ou model , et ces modèles ont souvent des attributs avec le même nom et le même type, tels que:

 // db table primary keyprivate int id;

C'est très courant, mais j'ai rencontré de nombreux collègues dans mon travail réel. Le système définit une classe avec le nom BaseModel ou RootModel , y place l' id d'attribut ci-dessus, puis tous les modèles de l'ensemble du projet héritent de cette classe Basemoddel. Je me demande si vous avez déjà rencontré de tels collègues? Quels sont les avantages et les inconvénients de l'écriture comme celle-ci?

Parlons d'abord des avantages. Si vous devez dire quels avantages il peut apporter, vous ne voyez aucun avantage substantiel, sauf pour taper le clavier plusieurs fois et manquer ces attributs dans la sous-classe. Cependant, cela a provoqué des choses très gênantes à la maintenance ultérieure du projet.

Parlons ensuite des problèmes potentiels de cette rédaction:

Un jour, pour certaines raisons, vous voulez trouver où utiliser l' id d'attribut dans la sous-classe A (héritage du Basemodel) dans le projet

Vous êtes intelligent et habilement utilisé, find usages dans l'IDE, puis vous constaterez que vous avez trouvé beaucoup d'emplacements d'utilisation, et beaucoup d'entre eux ne sont pas du tout ce qui vous intéresse. Mais il n'y a aucun moyen, vous avez également recherché l'emplacement d'utilisation de l'ID de propriété d'autres classes qui héritent de Basemodel. Si le projet n'est pas important, vous pouvez avoir moins de compétences. Et si le projet est un peu plus grand? Lorsque vous avez plus de 50 compétences en recherche, que ferez-vous ensuite?

• J'ai regardé les codes que j'ai recherchés un par un, et après avoir lu plus d'une douzaine ou vingt, j'ai commencé à les vaporiser, puis j'ai continué à chercher un par un?
• Commencez à pulvériser directement, puis regardez les codes que vous avez recherchés un par un?

Comment éviter cette situation? Autrement dit, n'utilisez pas BaseModel comme celui-ci pour utiliser l'héritage des attributs. Bien sûr, pour des raisons rigoureuses, je dois encore expliquer ce sens en détail. Je ne m'oppose pas complètement à l'héritage des attributs. Clarifions:

Ce que j'objette, c'est que tous les modèles de l'ensemble du projet héritent d'un Basemodel et mettent ensuite les propriétés communes dans le Basemodel

Cette idée est de noter que c'est pour l'ensemble du projet

Personnellement, je rencontre souvent des exemples des manuels négatifs ci-dessus, donc je vais en parler séparément. Je ne sais pas si cela s'est produit dans vos projets. Quoi qu'il en soit, j'ai été trompé par mes collègues depuis plusieurs fois.

Quant aux autres erreurs courantes liées à la «combinaison» et à «l'héritage», je n'y ai pas encore pensé (au moins je pense que personne ne le fera). Si je pense que c'est clairement à l'avenir, ou si les lecteurs ont d'autres suggestions, j'espère que vous pourrez laisser un message pour communiquer.