Чи є інтерфейс списку герметичною абстракцією?

Якщо у мене є змінна, що містить, Listвона може містити об'єкти безлічі різних типів, наприклад, ArrayListабо LinkedList. Різниця між a LinkedListі an ArrayListдосить велика. Велика поведінка методів O значно відрізняється. Наприклад, сортування, Listа потім його використання для здійснення двійкових пошуків - це цілком нормально, ArrayListале це не має сенсу для LinkedList.

Я б не сказав цього.

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

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

Крім того , не варто забувати , що є ще більш загальний інтерфейс , який часто буває досить функціональності і не спокушати вас , щоб зробити так багато припущень про продуктивності: Collection.

Всі нетривіальні абстракції, певною мірою, є негерметичними. Однак я не впевнений, що це стосується і тут. :-)

Абстракції стосуються поведінки. Якщо поведінка не визначає конкретну продуктивність (чого Listне має Java ), це деталізація реалізації - тобто не має значення.

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

1. Документуйте його в класі / інтерфейсі, до якого буде належати екземпляр списку.
2. Створіть новий інтерфейс - наприклад BinarySearchPerformantList(yuck!) - який визначає вимоги до продуктивності різних методів.

Варіант 2, мабуть, краща абстракція, але має додаткові накладні витрати.

У Java існує інтерфейс RandomAccess, який визначається як список із загальним постійним часом випадкового доступу (O (1) отримати, поставити тощо). Якщо ви вважаєте, що для вашого модуля потрібен список із тими характеристиками продуктивності, подумайте про використання RandomAccessзамість List. Якщо ви не відчуваєте необхідності вносити ці зміни (а це мало хто робить), можливо, Список не такий проникливий.

Ви маєте рацію, Список - це витікаюча абстракція. STL використовує ідею концепцій для моделювання цієї конкретної проблеми. Щоб використати ваш приклад, ArrayListмодель ітератора випадкового доступу, тоді як LinkedList моделює ітератор вперед . Різні концепції мають різні вимоги до продуктивності, що робить їх відповідними для різних алгоритмів .