Ne le fais pas; ça compliquera trop les choses et vous n'en aurez pas besoin
... est la réponse que j'aurais écrit ici il y a 2 ans. Maintenant, cependant, je n'en suis pas si sûr. En fait, ces derniers mois, j'ai commencé à migrer l'ancien code vers ce format, non pas parce que je n'ai rien de mieux à faire, mais parce que j'en avais vraiment besoin pour implémenter de nouvelles fonctionnalités ou modifier les existantes. Je comprends les aversions automatiques des autres ici à voir ce code, mais je pense que c'est quelque chose qui mérite une réflexion sérieuse.
Avantages
L'un des principaux avantages est la possibilité de modifier et d'étendre le code. Si tu utilises
class Point {
int x,y;
// other point operations
}
au lieu de simplement passer quelques entiers, ce qui est malheureusement le cas de nombreuses interfaces, il devient alors beaucoup plus facile d'ajouter ultérieurement une autre dimension. Ou changez le type en double
. Si vous l'utilisez List<Author> authors
ou le List<Person> authors
remplace List<String> authors
plus tard, il devient beaucoup plus facile d'ajouter plus d'informations à ce qu'un auteur représente. En écrivant cela comme cela, je me sens comme énonçant une évidence, mais en pratique, j’ai été coupable d’utiliser des cordes de cette façon plusieurs fois moi-même, surtout dans les cas où ce n’était pas évident au début, j’aurais besoin de plus de un string.
J'essaie actuellement de refactoriser une liste de chaînes qui est entrelacée dans tout mon code car j'ai besoin de plus d'informations là-bas et je sens la douleur: \
Au-delà de cela, je suis d'accord avec l'auteur du blog pour dire qu'il contient davantage d'informations sémantiques , ce qui facilite la compréhension du lecteur. Bien que les paramètres reçoivent souvent des noms significatifs et une ligne de documentation dédiée, ce n'est souvent pas le cas avec les champs ou les sections locales.
Le dernier avantage est la sécurité du type , pour des raisons évidentes, mais à mes yeux, c'est une chose mineure ici.
Désavantages
Cela prend plus de temps pour écrire . Écrire une petite classe est rapide et facile, mais pas sans effort, surtout si vous avez besoin de beaucoup de ces classes. Si vous vous arrêtez toutes les 3 minutes pour écrire une nouvelle classe de wrapper, cela peut aussi nuire à votre concentration. J'aimerais cependant penser que cet effort ne se produira généralement qu'à la première étape de l'écriture d'un morceau de code; Je peux généralement avoir rapidement une bonne idée de ce que les entités devront impliquer.
Cela peut impliquer un grand nombre de setters (ou de constructions) et de getters redondants . L'auteur du blog donne l'exemple vraiment laid de new Point(x(10), y(10))
au lieu de new Point(10, 10)
, et j'aimerais ajouter qu'un usage peut également impliquer des choses comme Math.max(p.x.get(), p.y.get())
au lieu de Math.max(p.x, p.y)
. Et le code long est souvent considéré comme plus difficile à lire, et à juste titre. Mais en toute honnêteté, j'ai l'impression que beaucoup de code déplace des objets, et que seules des méthodes choisies le créent, et encore moins ont besoin d'accéder à ses détails précis (ce qui n'est pas OOPy de toute façon).
Discutable
Je dirais que cela aide ou non à la lisibilité du code est discutable. Oui, plus d'informations sémantiques, mais un code plus long. Oui, il est plus facile de comprendre le rôle de chaque section locale, mais il est plus difficile de comprendre ce que vous pouvez en faire si vous ne lisez pas sa documentation.
Comme avec la plupart des écoles de pensée de programmation, je pense qu'il est malsain de pousser celui-ci à l'extrême. Je ne me vois jamais séparer les coordonnées x et y d'un type différent. Je ne pense pas que Count
nécessaire quand un int
devrait suffire. Je n'aime pas l' unsigned int
utilisation en C - bien que théoriquement bon, cela ne vous donne tout simplement pas assez d'informations, et cela interdit l'extension ultérieure de votre code pour prendre en charge cette valeur magique -1. Parfois, vous avez besoin de simplicité.
Je pense que ce blog est un peu extrême. Mais dans l’ensemble, j’ai appris d’une expérience douloureuse que l’idée de base est faite à partir des éléments appropriés.
J'ai une profonde aversion pour le code trop élaboré. Je le fais vraiment. Mais bien utilisé, je ne pense pas que cette sur-ingénierie.