Bonne ou mauvaise pratique pour masquer les collections Java avec des noms de classe significatifs?

Dernièrement, j'ai l'habitude de "masquer" les collections Java avec des noms de classes conviviaux. Quelques exemples simples:

// Facade class that makes code more readable and understandable.
public class WidgetCache extends Map<String, Widget> {
}

Ou:

// If you saw a ArrayList<ArrayList<?>> being passed around in the code, would you
// run away screaming, or would you actually understand what it is and what
// it represents?
public class Changelist extends ArrayList<ArrayList<SomePOJO>> {
}

Un collègue m'a fait remarquer que c'était une mauvaise pratique et introduisait un décalage / latence, tout en étant un anti-pattern OO. Je peux comprendre que cela introduise un très faible degré de performance, mais je ne peux pas imaginer que cela soit significatif. Je demande donc: est-ce bon ou mauvais de le faire et pourquoi?

Lag / latence? J'appelle BS à ce sujet. Il devrait y avoir exactement zéro frais généraux de cette pratique. ( Edit: il a été souligné dans les commentaires que cela peut en fait empêcher les optimisations effectuées par la machine virtuelle HotSpot. Je ne connais pas suffisamment l'implémentation de la machine virtuelle pour confirmer ou infirmer cela. Je me suis basé mon commentaire sur C ++. implémentation de fonctions virtuelles.)

Il y a une surcharge de code. Vous devez créer tous les constructeurs de la classe de base souhaitée, en transmettant leurs paramètres.

Je ne vois pas non plus cela comme un anti-modèle, en soi. Cependant, je le vois comme une opportunité manquée. Au lieu de créer une classe qui dérive la classe de base uniquement pour renommer, pourquoi ne pas créer une classe contenant la collection et offrant une interface améliorée spécifique à la casse? Votre cache de widgets doit-il vraiment offrir l'interface complète d'une carte? Ou devrait-il plutôt offrir une interface spécialisée?

De plus, dans le cas de collections, le modèle ne fonctionne tout simplement pas avec la règle générale d’utilisation d’interfaces, et non d’implémentations - c’est-à-dire que dans le code de collection simple, vous créez un HashMap<String, Widget>, puis vous l’assignez à une variable de type Map<String, Widget>. Votre WidgetCachene peut pas s'étendre Map<String, Widget>, car c'est une interface. Il ne peut s'agir d'une interface qui étend l'interface de base, car elle HashMap<String, Widget>n'implémente pas cette interface, pas plus que toute autre collection standard. Et bien que vous puissiez en faire une classe qui s'étend HashMap<String, Widget>, vous devez ensuite déclarer les variables comme WidgetCacheou Map<String, Widget>, et le premier vous perd la flexibilité nécessaire pour substituer une collection différente (peut-être la collection de chargement paresseux de certains ORM), tandis que le second défait le point. d'avoir la classe.

Certains de ces contrepoints s'appliquent également à la classe spécialisée proposée.

Ce sont tous des points à considérer. Ce peut être ou ne pas être le bon choix. Dans les deux cas, les arguments proposés par votre collègue ne sont pas valides. S'il pense que c'est un anti-modèle, il devrait le nommer.

Selon IBM, il s’agit en réalité d’un anti-modèle. Ces classes comme 'typedef' sont appelées types psuedo.

L'article l'explique beaucoup mieux que moi, mais je vais essayer de le résumer au cas où le lien tomberait:

• Tout code qui attend un WidgetCachene peut pas gérer unMap<String, Widget>
• Ces pseudotypes sont "viraux" lorsqu'ils utilisent plusieurs packages, ils entraînent des incompatibilités, alors que le type de base (juste une carte idiote <...>) aurait fonctionné dans tous les cas, dans tous les packages.
• Les pseudo-types sont souvent trop concrets, ils n'implémentent pas d'interfaces spécifiques car leurs classes de base implémentent uniquement la version générique.

Dans l'article, ils proposent l'astuce suivante pour rendre la vie plus facile sans utiliser de pseudo-types:

public static <K,V> Map<K,V> newHashMap() {
    return new HashMap<K,V>(); 
}

Map<Socket, Future<String>> socketOwner = Util.newHashMap();

Ce qui fonctionne grâce à l'inférence de type automatique.

(Je suis venu à cette réponse via cette question connexe de débordement de pile)

La performance atteinte serait tout au plus limitée à une recherche vtable, que vous êtes probablement déjà en train de subir. Ce n'est pas une raison valable pour s'y opposer.

La situation est suffisamment commune pour que la plupart des langages de programmation à typage statique aient une syntaxe spéciale pour les types de crénelage, généralement appelée un typedef. Java n'a probablement pas copié ceux-ci car à l'origine, il n'avait pas de types paramétrés. L'extension d'une classe n'est pas idéale, pour les raisons que Sebastian a si bien abordée dans sa réponse, mais cela peut constituer une solution de contournement raisonnable pour la syntaxe limitée de Java.

Les typedefs présentent de nombreux avantages. Ils expriment plus clairement l'intention du programmeur, avec un meilleur nom, à un niveau d'abstraction plus approprié. Ils sont plus faciles à rechercher à des fins de débogage ou de refactoring. Envisagez de trouver partout où a WidgetCacheest utilisé par opposition à trouver ces utilisations spécifiques de a Map. Ils sont plus faciles à modifier, par exemple si vous vous rendez compte par la suite que vous avez besoin d’un LinkedHashMapou de votre propre conteneur personnalisé.

Comme d’autres ont déjà mentionné, je vous suggère d’utiliser la composition plutôt que l’héritage, de sorte que vous ne puissiez exposer que les méthodes réellement nécessaires, avec des noms correspondant au cas d’utilisation souhaité. Les utilisateurs de votre classe ont-ils vraiment besoin de savoir qu’il WidgetCaches’agit d’une carte? Et être capable de faire avec tout ce qu'ils veulent? Ou ont-ils simplement besoin de savoir qu'il s'agit d'un cache pour les widgets?

Exemple de classe de ma base de code, avec la solution au problème similaire que vous avez décrit:

public class Translations {

    private Map<Locale, Properties> translations = new HashMap<>();

    public void appendMessage(Locale locale, String code, String message) {
        /* code */
    }

    public void addMessages(Locale locale, Properties messages) {
        /* code */
    }

    public String getMessage(Locale locale, String code) {
        /* code */
    }

    public boolean localeExists(Locale locale) {
        /* code */
    }
}

Vous pouvez voir qu’en interne, c’est «juste une carte», mais l’interface publique ne l’affiche pas. Et il a des méthodes "conviviales pour les programmeurs" comme appendMessage(Locale locale, String code, String message)pour un moyen plus facile et plus significatif d'insérer de nouvelles entrées. Et les utilisateurs de classe ne peuvent pas faire, par exemple translations.clear(), parce que Translationsne s'étend pas Map.

Facultativement, vous pouvez toujours déléguer certaines des méthodes nécessaires à la carte utilisée en interne.

Je vois cela comme un exemple d'abstraction significative. Une bonne abstraction a quelques traits:

1. Il cache des détails d'implémentation qui ne sont pas pertinents pour le code qui le consomme.

2. C'est aussi complexe que cela doit être.

En étendant, vous exposez toute l'interface du parent, mais dans de nombreux cas, une grande partie de cette information est peut-être mieux masquée. Vous voudrez donc faire ce que Sebastian Redl suggère, préférer la composition à l'héritage et ajouter une instance du parent comme un membre privé de votre classe personnalisée. Toutes les méthodes d'interface utiles pour votre abstraction peuvent facilement être déléguées (dans votre cas) à la collection interne.

En ce qui concerne l’impact sur les performances, il est toujours judicieux d’optimiser d’abord le code pour en améliorer la lisibilité. Si un impact sur les performances est suspecté, profilez le code afin de comparer les deux implémentations.

+1 aux autres réponses ici. J'ajouterai également que c'est en fait une très bonne pratique de la part de la communauté DDD (Domain Driven Design). Ils préconisent que votre domaine et les interactions avec ce dernier aient une signification de domaine sémantique, par opposition à la structure de données sous-jacente. A Map<String, Widget>pourrait être un cache, mais cela pourrait aussi être autre chose. Ce que vous avez correctement fait dans Mon opinion pas si humble (IMNSHO) est de modéliser ce que la collection représente, dans ce cas un cache.

J'ajouterai une modification importante dans le fait que le wrapper de classe de domaine autour de la structure de données sous-jacente devrait probablement également contenir d'autres variables ou fonctions membres qui en font réellement une classe de domaine avec des interactions, par opposition à une structure de données uniquement (si seulement Java avait des types de valeur , nous les aurons en Java 10 - promis!)

Il sera intéressant de voir quel impact les flux de Java 8 auront sur tout cela. J'imagine que certaines interfaces publiques préféreront peut-être traiter un Stream de (insérer une primitive Java commune ou String) par opposition à un objet Java.