POO


1. [Obligatoire] Évitez d'accéder aux variables statiques ou aux méthodes statiques de cette classe via les références d'objet d'une classe. Cela augmentera inutilement l'analyse du compilateur dans les scripts.


2. [Obligatoire] Toutes les méthodes de remplacement doivent être annotées avec @Override.

Contre-exemple : getObject() et obtenez 0 problème object(). L'une est la lettre O et l'autre le chiffre 0. Ajoutez @Override

pour déterminer avec précision si la substitution a réussi. De plus, si la signature de la méthode est modifiée dans une classe abstraite, sa classe d'implémentation compilera et signalera immédiatement une erreur.


3. [Obligatoire] Les paramètres de variable Java ne peuvent être utilisés que s'ils ont le même type de paramètre et la même signification commerciale. Évitez d'utiliser Object.

Remarque : Les paramètres variables doivent être placés à la fin de la liste des paramètres. (Les étudiants sont encouragés à éviter autant que possible la programmation de paramètres variables)

Exemple : public User getUsers (String type, Integer... ids)

4. [Obligatoire] En principe, la signature de méthode de la signature d'interface exposée à l'extérieur ne peut pas être modifié. Évitez tout impact sur les appelants de l'interface. L'annotation @Deprecated doit être ajoutée lorsque l'interface est obsolète, et la nouvelle interface ou le nouveau service doit être clairement expliqué.

5. [Obligatoire] Les classes ou méthodes obsolètes ne peuvent pas être utilisées.

Remarque :
La méthode decode(String encodeStr) dans java . net URLDecoder est obsolète et le decode à deux paramètres (String source, String encode) doit être utilisé à la place. Puisque le fournisseur d'interface est clairement une interface obsolète, il est obligé de fournir une nouvelle interface en même temps qu'un appelant, il est obligé de vérifier la nouvelle implémentation de la méthode obsolète ;

6. [Obligatoire] La méthode égale de Object est susceptible de lever une exception de pointeur nul. Vous devez utiliser des constantes ou des objets avec certaines valeurs pour appeler equals.

Exemple positif :

" test " .equals(object);

Contre-exemple :

object.equals( " test " );

Explication : Il est recommandé d'utiliser java util Objects # equals . (introduit dans JDK 7) Classe utilitaire)

7 [Obligatoire] Toutes les comparaisons de valeurs entre des objets de classe d'empaquetage du même type doivent utiliser la méthode égale.

Explication : Pour l'affectation Integer var =? entre -128 et 127, l'objet Integer est généré dans le cache IntegerCache, et les objets Integer dans cette plage peuvent être directement utilisés == pour effectuer. Jugement, mais toutes les données en dehors de cette plage seront générées sur le tas et les objets existants ne seront pas réutilisés. C'est un gros piège Il est recommandé d'utiliser la méthode égale pour le jugement.


8. [Obligatoire] Les normes d'utilisation pour les types de données de base et les types de données packagés sont les suivantes :

1) Tous les attributs de classe POJO doivent utiliser des types de données packagés.

2) La valeur de retour et les paramètres des méthodes RPC doivent utiliser des types de données encapsulés.

3) Toutes les variables locales [recommandé] utilisent des types de données de base.

Remarque : L'attribut de classe POJO n'a pas de valeur initiale pour rappeler aux utilisateurs qu'ils doivent explicitement attribuer eux-mêmes la valeur lorsqu'ils ont besoin de l'utiliser. Tout problème

NPE ou contrôle d'entreposage est assuré par l'utilisateur.

Exemple positif : Le résultat de la requête de la base de données peut être nul car le déballage et la réception automatiques avec des types de données de base présentent des risques NPE.

Contre-exemple : Par exemple, affichez la hausse et la baisse du montant total de la transaction, c'est-à-dire plus ou moins x %, x est le type de données de base, et le service RPC est appelé lorsque l'appel échoue. , la valeur par défaut est renvoyée et la page affiche : 0 %, ce qui est déraisonnable et doit être affiché sous forme de tiret -. Par conséquent, la valeur nulle du type de données encapsulé peut représenter des informations supplémentaires, telles que : un échec d'appel à distance et une sortie anormale.


9. [Obligatoire] Lors de la définition de classes POJO telles que DO / DTO / VO, ne définissez aucune valeur par défaut d'attribut.

Contre-exemple : La valeur par défaut de gmtCreate de la classe POJO est new Date(); cependant, cet attribut n'est pas défini sur une valeur spécifique lors de l'extraction des données. Ce champ est également mis à jour lorsque d'autres champs sont mis à jour, ce qui entraîne. une heure de création est modifiée à l'heure actuelle.


10. [Obligatoire] Lors de l'ajout de nouveaux attributs à la classe de sérialisation, veuillez ne pas modifier le champ SerialVersionUID pour éviter un échec de désérialisation et éviter le chaos de la désérialisation, veuillez modifier la valeur SerialVersionUID ;

Remarque :

Notez qu'un SerialVersionUID incohérent générera une exception d'exécution de sérialisation.

11. [Obligatoire] Il est interdit d'ajouter une logique métier dans la méthode de construction. S'il existe une logique d'initialisation, veuillez la mettre dans la méthode init.

12. [Obligatoire] La classe POJO doit écrire la méthode toString. Lorsque vous utilisez l'outil de l'IDE : source > generate toString
, si vous héritez d'une autre classe POJO, assurez-vous d'ajouter super .

Remarque : Lorsqu'une exception est levée lors de l'exécution de la méthode, vous pouvez directement appeler la méthode toString() de POJO pour imprimer sa valeur d'attribut, ce qui est pratique pour le dépannage

.


13. [Recommandation] Lorsque vous utilisez index pour accéder au tableau obtenu par la méthode split de String, vous devez vérifier s'il y a du contenu après le dernier délimiteur, sinon il y a un risque de lever une exception IndexOutOfBoundsException.

Instructions :

String str = "a,b,c,,";
String[] ary = str.split(",");
//预期大于 3,结果是 3
System.out.println(ary.length);


14. [Recommandation] Lorsqu'une classe a plusieurs constructeurs, ou plusieurs méthodes portant le même nom, ces méthodes doivent être placées ensemble afin de faciliter la lecture.


15. [Recommandé] L'ordre de définition des méthodes au sein d'une classe est : méthode publique ou méthode protégée > méthode privée > méthode getter/setter

.

Explication : Les méthodes publiques sont les méthodes qui préoccupent le plus les appelants et les responsables de la classe, et sont mieux affichées sur le premier écran, bien que les méthodes protégées ne concernent que les sous-classes, elles peuvent également être des méthodes principales sous ; le « mode de conception de modèle » ; Généralement, il n'est pas nécessaire de prêter une attention particulière à l'extérieur des méthodes privées, car la valeur des informations sur la méthode est faible, toutes les méthodes getter/setter de Service et DAO le sont ; placé à la fin du corps de classe. 16. [Recommandation] Dans la méthode setter, le nom du paramètre est cohérent avec le nom de la variable membre de la classe, this. Dans les méthodes

getter/setter, essayez de ne pas ajouter de logique métier et d'augmenter la difficulté du dépannage.


Contre-exemple :

public Integer getData(){
if(true) {
return data + 100;
} else {
return data - 100;
}
}

17 [Recommandation] Dans le corps de la boucle, utilisez la méthode append de StringBuilder pour développer la méthode de connexion par chaîne.

Contre-exemple :

String str = "start";
for(int i=0; i<100; i++){
str = str + "hello";
}

Explication :

Le fichier de bytecode décompilé montre que chaque boucle créera un nouvel objet StringBuilder, puis effectuera l'opération append, et enfin renverra l'objet String via la méthode toString, provoquant une perte de temps. ressources mémoire.

18. [Recommandation] Final peut améliorer l'efficacité de la réponse du programme lorsqu'il est déclaré comme final :

1) Variables qui n'ont pas besoin d'être réaffectées, y compris les attributs de classe et les variables locales.


2) Ajoutez final avant le paramètre objet, ce qui signifie que le point de référence ne peut pas être modifié.

3) Les méthodes de classe ne doivent absolument pas être remplacées.

19. [Recommandé] Utilisez la méthode clone d'Object avec prudence pour copier des objets.

Remarque : La méthode clone de l'objet
est une copie superficielle par défaut. Si vous souhaitez implémenter une copie complète, vous devez remplacer la méthode clone pour copier l'objet attribut

.

20. [Recommandé] Contrôle d'accès strict aux membres de la classe et aux méthodes :

1) Si les objets externes ne peuvent pas être créés directement via new, alors le constructeur doit être privé.

2) Les classes d'outils ne sont pas autorisées à avoir des constructeurs publics ou par défaut.

3) Les variables membres de classe non statiques et partagées avec les sous-classes doivent être protégées.

4) Les variables membres non statiques de classe ne sont utilisées que dans cette classe et doivent être privées.

5) Les variables membres statiques de classe doivent être privées si elles ne sont utilisées que dans cette classe.

6) S'il s'agit d'une variable membre statique, vous devez vous demander si elle est définitive.

7) Les méthodes membres de la classe ne peuvent être appelées qu'au sein de la classe et doivent être privées.

8) Les méthodes membres de classe ne sont publiques que pour les classes héritées, elles sont donc limitées aux classes protégées.

Remarque : Contrôlez strictement la portée d'accès de toute classe, méthode, paramètre ou variable. Un champ d’accès trop large n’est pas propice au découplage des modules. Réflexions : s'il s'agit d'une méthode privée, supprimez-la si vous le souhaitez, mais s'il s'agit d'une méthode de service public ou d'une variable membre publique, supprimez-la et vos paumes transpireront un peu ? Les variables sont comme vos propres enfants. Essayez de les garder à votre portée. Si elles circulent sans restrictions, vous serez inquiet.