Il y a encore des gens dans le monde qui n'utilisent pas de génériques jave dans le "codage ordinaire". Je peux le croire avec des modèles C ++, mais des génériques? Ils ne sont même pas difficiles à apprendre / à utiliser. Sérieusement, les meilleures fonctionnalités de Java et C ++ sont respectivement les génériques et les modèles.
La meilleure façon de convaincre les gens est de faire un argument convaincant, de ne pas menacer et d'avoir raison.
Tant que vous ne faites pas quelque chose comme l'utilisation de modèles comme langage de programmation, le polymorphisme paramétrique (génériques / modèles) est presque certainement bon.
1. Évite la duplication de code.
C'est évident, mais le code polymorphe est un code général. C'est pourquoi il est appelé générique.
2. Prend en charge une meilleure vérification statique.
Sans polymorphisme paramétrique, vous finissez par écrire des choses comme public Object clone()
ou public boolean equals(object b)
qui ne sont pas que des abominations, ils ont des types qui ne fournissent aucune information sur ce qu'ils font et finissent invariablement par lancer des exceptions partout. L'alternative au polymorphisme paramétrique est le lancer partout
3. Le code OOP du polymorphisme non paramétrique est fondamentalement incapable de gérer correctement les "méthodes binaires".
Vous les utilisez souvent.
4. C'est la meilleure pratique
En Java, l'utilisation de génériques est considérée comme la meilleure pratique (voir Effective Java par Josh Bloch). Les grands penseurs C ++ comme Sutter et Alexandrescu encouragent également l'utilisation de modèles pour résoudre une variété de problèmes.
5. Il correspond au paradigme OO.
Souvent, les gens ne le remarquent pas, mais la combinaison de sous-typage et de génériques produit un système beaucoup plus puissant expressif et orienté objet que n'importe quel système avec un seul d'entre eux.
Considérez les mixins de Scala. Il s'agit d'une fonctionnalité intéressante qui vous permet de rassembler vos objets à partir de composants. Les génériques et les modèles peuvent simuler certains de ces avantages. Par exemple, supposons que l'un de vos objets utilise une base de données. Une bonne conception vous permettrait d'abstraire l'accès à la base de données dans une classe distincte. Si cela est fait correctement, cela vous permet non seulement de vous moquer de votre magasin de données (clé de la testabilité), cela signifie également que vous pouvez ajouter des implémentations alternatives comme cette nouvelle base de données sans SQL. Ici cependant, vous pourriez avoir un problème, quelle que soit l'implémentation que vous utilisez, vous obtiendrez différentes capacités de votre objet métier.
Des génériques à la rescousse!
public class Business<S extends Datastore>{
private S store; ...
}
Vous pouvez maintenant commencer à différencier statiquement vos Business
objets en fonction de la capacité à utiliser des fonctionnalités spécifiques à la base de données. Vous avez encore besoin de vérifications d'exécution et de cast, mais vous pouvez commencer à construire BEAUCOUP de meilleur code.
et
6. Le code normal n'existe pas.
Il n'y a que trois choses dans l'univers de programmation:
- bibliothèques,
- configurations, et
- mauvais code.
Si vous ne pensez pas à votre code comme à une bibliothèque, vous avez de sérieux problèmes lorsque les exigences de votre projet changent. L'architecture est (sans doute) l'art de concevoir de bonnes API.
Je trouve cette attitude stupéfiante. Après vous être habitué à la programmation avec des types paramétrés, ne pas les utiliser rend tout simplement pénible. Et, Java et C ++ ont un tas de points difficiles auxquels ils aident à remédier.