1. La première lettre du nom de la classe doit être en majuscule. La première lettre des champs, des méthodes et des objets (poignées) doit être en minuscule. Comme pour tous les identifiants, tous les mots contenus doivent être rapprochés, la première lettre du mot intermédiaire étant en majuscule. Par exemple:
Copiez le code comme suit : ThisIsAClassName
thisIsMethodOrFieldName
Si un caractère d'initialisation constant apparaît dans la définition, mettez toutes les lettres en majuscule dans l'identifiant de type de base final statique. Cela les marquera comme constantes de compilation.
Les packages Java sont un cas particulier : ils sont tous en minuscules, même les mots du milieu. Pour les noms d'extension de nom de domaine, tels que com, org, net ou edu, etc., tous doivent être en minuscules (c'est aussi l'une des différences entre Java 1.1 et Java 1.2).
2. Lors de la création d'une classe à usage général, veuillez adopter la « forme classique » et inclure les définitions des éléments suivants :
Copiez le code comme suit :
est égal()
code de hachage()
àChaîne()
clone()（implémenter Cloneable）
implémenter sérialisable
3. Pour chaque classe que vous créez, pensez à placer un main(), qui contient le code permettant de tester cette classe. Pour utiliser les classes d'un projet, nous n'avons pas besoin de supprimer le code de test. Si des modifications de quelque nature que ce soit sont apportées, il est facile de revenir aux tests. Le code sert également d'exemple sur la façon d'utiliser les classes.
4. La méthode doit être conçue sous la forme d'une unité fonctionnelle brève, qui peut être utilisée pour décrire et implémenter une partie d'interface de classe discontinue. Idéalement, l’approche devrait être concise et précise. Si la longueur est grande, envisagez de la diviser en morceaux plus courts d'une manière ou d'une autre. Cela facilite également la réutilisation du code au sein d'une classe (parfois, les méthodes doivent être très volumineuses, mais elles ne doivent quand même faire que la même chose).
5. Lors de la conception d'une classe, veuillez vous mettre à la place du programmeur client (la méthode d'utilisation de la classe doit être très claire). Ensuite, mettez-vous à la place de la personne qui gère le code (anticipez les types de modifications susceptibles d’être apportées et réfléchissez aux moyens de les simplifier).
6. Rendez le cours aussi court et concis que possible et résolvez uniquement un problème spécifique. Voici quelques suggestions pour la conception des classes :
1. Une instruction switch complexe : pensez à utiliser le mécanisme "polymorphe"
2. Un grand nombre de méthodes impliquent des opérations de types très différents : pensez à utiliser plusieurs classes pour les implémenter séparément.
3. De nombreuses variables membres ont des caractéristiques très différentes : pensez à utiliser plusieurs classes
7. Rendre tout aussi « privé » que possible. Vous pouvez rendre une partie de la bibliothèque "publique" (une méthode, une classe, un champ, etc.) afin qu'elle ne puisse jamais être supprimée. Si vous le forcez, cela peut détruire le code existant d'autres personnes, les obligeant à le réécrire et à le concevoir. Si vous ne publiez que ce que vous devez publier, vous pouvez librement modifier tout le reste. Dans les environnements multithread, la confidentialité est un facteur particulièrement important. Seuls les champs privés peuvent être protégés contre une utilisation non synchronisée.
8. Méfiez-vous du « syndrome de l’objet géant ». Pour certains novices habitués à la programmation séquentielle et nouveaux dans le domaine de la POO, ils aiment souvent d'abord écrire un programme d'exécution séquentielle, puis l'intégrer dans un ou deux objets énormes. Selon les principes de programmation, les objets doivent exprimer le concept de l’application, et non l’application elle-même.
9. Si vous devez effectuer une programmation disgracieuse, vous devez au moins mettre le code dans une classe.
10. Chaque fois que vous constatez que les classes sont très étroitement intégrées, vous devez réfléchir à l'opportunité d'utiliser des classes internes pour améliorer le travail de codage et de maintenance (voir « Amélioration du code avec les classes internes » au chapitre 14, section 14.1.2).
11. Ajoutez des commentaires aussi soigneusement que possible et utilisez la syntaxe du document de commentaires javadoc pour générer votre propre documentation de programme.
12. Évitez d'utiliser des « nombres magiques ». Ces nombres sont difficiles à adapter au code. Si vous devez le modifier à l'avenir, cela deviendra sans aucun doute un cauchemar, car vous ne savez pas si « 100 » fait référence à la « taille du tableau » ou à « tout autre chose ». Par conséquent, nous devons créer une constante, lui donner un nom convaincant et descriptif et utiliser des identifiants de constante dans tout le programme. Cela rend le programme plus facile à comprendre et à maintenir.
13. En ce qui concerne les générateurs et les exceptions, vous souhaitez généralement relancer toute exception interceptée dans le générateur si elle a provoqué l'échec de la création de cet objet. De cette façon, l'appelant ne continuera pas à penser aveuglément que l'objet a été créé correctement.
14. Une fois que le programmeur client a fini d'utiliser l'objet, si votre classe nécessite un travail de nettoyage, envisagez de placer le code de nettoyage dans une méthode bien définie, en utilisant un nom comme cleanup() pour indiquer clairement votre utilisation. De plus, un indicateur booléen peut être placé dans la classe pour indiquer si l'objet a été effacé. Dans la méthode finalize() de la classe, assurez-vous que l'objet a été effacé et qu'une classe qui hérite de RuntimeException a été supprimée (si ce n'est déjà fait), indiquant ainsi une erreur de programmation. Avant d'adopter une solution comme celle-ci, assurez-vous que finalize() fonctionne sur votre système (vous devrez peut-être appeler System.runFinalizersOnExit(true) pour garantir ce comportement).
15. Dans une portée spécifique, si un objet doit être effacé (non traité par le mécanisme de récupération de place), veuillez utiliser la méthode suivante : initialisez l'objet ; en cas de succès, entrez immédiatement un bloc try contenant une clause final pour démarrer le travail de nettoyage. .
16. Si vous devez remplacer (annuler) finalize() pendant le processus d'initialisation, n'oubliez pas d'appeler super.finalize() (si Object appartient à notre super classe directe, ce n'est pas nécessaire). Lors du processus de substitution de finalize(), l'appel à super.finalize() doit être la dernière action, et non la première, pour garantir que les composants de la classe de base sont toujours valides lorsqu'ils sont nécessaires.
17. Lors de la création de collections d'objets de taille fixe, transférez-les vers un tableau (surtout si vous envisagez de renvoyer cette collection à partir d'une méthode). De cette façon, nous pouvons profiter des avantages de la vérification du type de tableau au moment de la compilation. De plus, le destinataire du tableau n'a peut-être pas besoin de "caster" l'objet dans le tableau pour pouvoir l'utiliser.
18. Essayez d'utiliser des interfaces au lieu de classes abstraites. Si vous savez que quelque chose sera une classe de base, votre première option devrait être de le transformer en interface. Ce n'est que lorsque vous devez utiliser des définitions de méthode ou des variables membres que vous devez en faire une classe abstraite. Une interface décrit essentiellement ce que le client veut faire, tandis qu'une classe est dédiée (ou permet) des détails d'implémentation spécifiques.
19. À l'intérieur du constructeur, effectuez uniquement les travaux nécessaires pour remettre l'objet dans le bon état. Dans la mesure du possible, évitez d'appeler d'autres méthodes, car ces méthodes peuvent être remplacées ou annulées par d'autres, produisant des résultats imprévisibles pendant le processus de construction (voir le chapitre 7 pour plus de détails).
20. Les objets ne doivent pas simplement contenir des données ; leur comportement doit également être bien défini.
21. Lors de la création d'une nouvelle classe basée sur une classe existante, veuillez d'abord sélectionner « Nouveau » ou « Créer ». Ce problème ne doit être pris en compte que si vos propres exigences de conception doivent être héritées. Si l’héritage est utilisé là où la nouvelle création est autorisée, la conception entière devient inutilement complexe.
22. Utilisez l'héritage et la couverture des méthodes pour exprimer la différence entre les comportements et utilisez des champs pour exprimer la différence entre les états. Un exemple très extrême est de représenter les couleurs par héritage de différentes classes, ce qu'il faut absolument éviter : utiliser directement un champ "color".
23. Pour éviter des problèmes lors de la programmation, assurez-vous que chaque nom correspond à une seule classe, là où pointe votre chemin de classe. Sinon, le compilateur pourrait d'abord trouver une autre classe portant le même nom et signaler un message d'erreur. Si vous pensez avoir rencontré un problème de chemin de classe, essayez de rechercher un fichier .class portant le même nom à chaque point de départ du chemin de classe.
24. Lors de l'utilisation d'"adaptateurs" d'événements dans Java 1.1 AWT, il est particulièrement facile de rencontrer un piège. Si une méthode d'adaptateur est remplacée et que la méthode d'orthographe n'est pas particulièrement particulière, le résultat final sera d'ajouter une nouvelle méthode au lieu de remplacer la méthode existante. Cependant, comme cela est parfaitement légal, vous ne recevrez aucun message d'erreur du compilateur ou du système d'exécution, mais votre code se comportera simplement de manière incorrecte.
25. Utiliser des solutions de conception raisonnables pour éliminer les « pseudo-fonctions ». Autrement dit, si vous n'avez besoin de créer qu'un seul objet de la classe, ne vous limitez pas à l'application à l'avance et ajoutez un commentaire « n'en générer qu'un seul ». Veuillez envisager de l'encapsuler dans un formulaire « enfant unique ». Si vous avez beaucoup de code dispersé dans le programme principal utilisé pour créer vos propres objets, envisagez d'adopter une solution créative pour encapsuler ce code.
26. Méfiez-vous de la « paralysie par l'analyse ». N'oubliez pas que quoi qu'il arrive, vous devez comprendre à l'avance l'état de l'ensemble du projet, puis examiner les détails. Parce que vous avez une compréhension de la situation globale, vous pouvez rapidement reconnaître certains facteurs inconnus et éviter de tomber dans une « logique morte » lors de l'examen des détails.
27. Méfiez-vous de « l’optimisation prématurée ». Faites-le fonctionner en premier, pensez à devenir plus rapide plus tard, mais optimisez-le uniquement si vous le devez et s'il est prouvé qu'il existe un goulot d'étranglement en termes de performances dans une partie du code. À moins d’utiliser des outils spécialisés pour analyser les goulots d’étranglement, vous perdez probablement votre temps. Le coût implicite de l’amélioration des performances est que votre code devient plus difficile à comprendre et à maintenir.
28. N'oubliez pas que vous passez beaucoup plus de temps à lire du code qu'à l'écrire. Une conception claire donne un programme facile à comprendre, mais les commentaires, les explications minutieuses et quelques exemples sont souvent inestimables. Ils sont très importants, tant pour vous que pour ceux qui vous suivent. Si vous en doutez encore, imaginez votre frustration en essayant de trouver des informations utiles dans la documentation Java en ligne, et vous pourriez être convaincu.
29. Si vous pensez avoir effectué une bonne analyse, conception ou mise en œuvre, veuillez modifier légèrement votre point de vue. Essayez d'inviter des personnes extérieures, pas nécessairement des experts, mais des personnes provenant d'autres secteurs de l'entreprise. Demandez-leur de regarder votre travail avec un regard complètement neuf et de voir s'ils peuvent repérer des problèmes dont vous étiez aveugle. En adoptant cette méthode, nous pouvons souvent identifier certains problèmes clés au stade le plus approprié pour la modification et éviter la perte d'argent et d'énergie causée par la résolution des problèmes après la sortie du produit.
30. Une bonne conception peut apporter les meilleurs résultats. Bref, il faut souvent beaucoup de temps pour trouver la solution la plus adaptée à un problème donné. Mais une fois que vous aurez trouvé la bonne méthode, votre futur travail sera beaucoup plus facile et vous n’aurez pas à endurer des heures, des jours ou des mois de lutte douloureuse. Notre travail acharné apportera les plus grandes récompenses (même incommensurables). Et parce que j'y ai consacré beaucoup d'efforts, j'ai finalement obtenu un excellent plan de conception, et le frisson du succès est également passionnant. Résistez à la tentation de vous précipiter dans le travail, qui n’en vaut souvent pas la peine.