Хороша чи погана практика маскувати колекції Java значущими іменами класів?

Останнім часом я звик "маскувати" колекції Java під назви класів, зручних для людини. Деякі прості приклади:

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

Або:

// 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>> {
}

Колега вказував мені, що це погана практика, і вводить відставання / затримку, а також є анти-схемою OO. Я можу зрозуміти, що це дуже низька ступінь продуктивності, але не можу уявити, що це зовсім важливо. Тож я запитую: це добре чи погано робити, і чому?

Затримка / затримка? Я подзвоню БС з цього приводу. З цієї практики має бути рівно нульові накладні витрати. ( Редагувати: У коментарях було зазначено, що це може насправді гальмувати оптимізацію, яку виконує HotSpot VM. Я не знаю достатньо про реалізацію VM, щоб підтвердити або спростувати це. Я базував свій коментар на C ++ реалізація віртуальних функцій.)

Є якийсь код накладних витрат. Ви повинні створити всі конструктори з базового класу, який потрібно, пересилаючи їх параметри.

Я також не розглядаю це як анти-візерунок. Однак я вважаю це пропущеною можливістю. Замість того, щоб створити клас, який отримує базовий клас просто заради перейменування, як ви замість цього створити клас, який містить колекцію та пропонує покращений інтерфейс, що стосується конкретного випадку? Чи повинен ваш кеш-віджет дійсно пропонувати повний інтерфейс карти? Або він повинен запропонувати спеціалізований інтерфейс?

Крім того, у випадку з колекціями шаблон просто не працює разом із загальним правилом використання інтерфейсів, а не реалізацій - тобто в простому коді колекції ви створили б HashMap<String, Widget>і потім призначили його змінній типу Map<String, Widget>. Ваш WidgetCacheне може поширюватися Map<String, Widget>, тому що це інтерфейс. Це не може бути інтерфейс, що розширює базовий інтерфейс, тому HashMap<String, Widget>що не реалізує цей інтерфейс, а також жодна інша стандартна колекція. І хоча ви можете зробити його класом, який розширюється HashMap<String, Widget>, тоді вам доведеться оголосити змінні як WidgetCacheабо Map<String, Widget>, і перший втрачає вам гнучкість замінити іншу колекцію (можливо, якась лінива колекція завантаження ORM), а другий тип перемагає крапку мати клас.

Деякі з цих контрапунктів стосуються і мого запропонованого спеціалізованого класу.

Це все, що слід врахувати. Це може бути, а може і не бути правильним вибором. В будь-якому випадку запропоновані вашими колегами аргументи не вірні. Якщо він вважає, що це анти-модель, він повинен її назвати.

На думку IBM, це насправді є антидіаграмою. Такі класи типу typedef називаються типами psuedo.

У статті йдеться про це набагато краще, ніж я, але спробую підсумувати його, якщо посилання знизиться:

• Будь-який код, який очікує, що WidgetCacheне може обробити aMap<String, Widget>
• Ці псевдотипи є "вірусними" при використанні декількох пакетів, вони призводять до несумісності, тоді як базовий тип (просто дурна карта <...>) працював би у всіх випадках у всіх пакунках.
• Псевдо типи часто конкретні, вони не реалізують конкретні інтерфейси, оскільки їх базові класи реалізують лише загальну версію.

У статті вони пропонують такий трюк, щоб полегшити життя без використання псевдотипів:

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

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

Що працює завдяки автоматичному виводу типу.

(Я прийшов до цієї відповіді з допомогою цієї пов'язаної з переповненням стека питання)

Показ ефективності максимум обмежуватиметься стабільним пошуком, який ви, швидше за все, вже здійснюєте. Це не вагома причина протидіяти цьому.

Ситуація є достатньо поширеною, що більшість усіх мов програмування, які мають статичний тип, мають спеціальний синтаксис для псевдонімових типів, який зазвичай називають a typedef. Java, ймовірно, не копіювала їх, оскільки спочатку не мала параметрів. Розширення класу не є ідеальним через причини, які Себастьян так добре висвітлював у своїй відповіді, але це може бути розумним вирішенням обмеженого синтаксису Java.

Typedefs має ряд переваг. Вони висловлюють наміри програміста більш чітко, з кращим іменем, на більш відповідному рівні абстракції. Їх простіше шукати для налагодження чи рефакторингу. Розглянемо, що пошук скрізь a WidgetCacheвикористовується в порівнянні з пошуком конкретних цілей використання Map. Їх легше змінити, наприклад, якщо згодом виявиться, що вам потрібен LinkedHashMapзамість цього або навіть власний спеціальний контейнер.

Я пропоную вам, як уже згадувалося, використовувати композицію над успадкуванням, тому ви можете розкривати лише методи, які дійсно потрібні, з іменами, що відповідають випадку призначеного використання. Чи дійсно користувачам вашого класу потрібно знати, що WidgetCacheце карта? І чи зможуть зробити з цим все, що хочуть? Або вони просто повинні знати, що це кеш для віджетів?

Приклад класу з моєї бази даних з рішенням подібної проблеми, яку ви описали:

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 */
    }
}

Ви бачите, що всередині це "просто карта", але публічний інтерфейс цього не показує. І в ньому є методи, зручні для програмістів, як appendMessage(Locale locale, String code, String message)для більш легкого і змістовного способу вставки нових записів. І, наприклад, користувачі класу не можуть це зробити translations.clear(), тому що Translationsце не розширюється Map.

За бажанням, ви завжди можете делегувати деякі необхідні методи для внутрішньо використовуваної карти.

Я бачу це як приклад змістовної абстракції. Хороша абстракція має кілька рис:

1. Він приховує деталі реалізації, які не мають значення для коду, який його споживає.

2. Він лише такий складний, як і повинен бути.

Розширюючи, ви відкриваєте весь інтерфейс батьків, але в багатьох випадках більша частина цього може бути краще прихованою, тому ви хочете зробити те, що пропонує Себастьян Редл, і надайте перевагу композиції над успадкуванням і додайте екземпляр батьків як приватний член вашого користувацького класу. Будь-який з методів інтерфейсу, який має сенс для вашої абстракції, можна легко делегувати (у вашому випадку) внутрішній колекції.

Що стосується впливу на ефективність, то завжди добре спочатку оптимізувати код для читабельності, а якщо підозрюється вплив на ефективність, профіліруйте код для порівняння двох реалізацій.

+1 до інших відповідей тут. Я також додам, що спільнотою Design Driven Design (DDD) це насправді вважається дуже хорошою практикою. Вони виступають за те, щоб ваш домен та його взаємодія мали мати смислове значення домену на відміну від основної структури даних. A Map<String, Widget>може бути кешем, але він може бути і чимось іншим, те, що ви правильно зробили в My Not So Humble Opinion (IMNSHO), - це моделювати те, що представляє колекція, у цьому випадку кеш.

Я додаю важливу редакцію в тому, що обгортка доменного класу навколо основної структури даних, ймовірно, також повинна мати інші змінні або функції члена, які справді роблять його доменним класом з взаємодіями на відміну від просто структури даних (якщо тільки Java мала типи значень , ми отримаємо їх на Java 10 - обіцяємо!)

Буде цікаво побачити, який вплив потоки Java 8 матимуть на все це, я можу уявити, що, можливо, деякі публічні інтерфейси вважають за краще мати справу з потоком (вставити загальний Java примітив або String) на відміну від об’єкта Java.