Чи є якийсь практичний спосіб, щоб пов'язана структура вузла була непорушною?

Я вирішив написати список, пов'язаний окремо, і склався план зробити внутрішню пов'язану структуру вузла незмінною.

Хоча я наткнувся на корч Скажіть, у мене є такі пов'язані вузли (з попередніх addоперацій):

1 -> 2 -> 3 -> 4

і сказати, що я хочу додати 5.

Для цього, оскільки вузол 4є незмінним, мені потрібно створити нову копію 4, але замінити його nextполе новим вузлом, що містить a 5. Проблема зараз 3полягає в посиланні на старе 4; той, що не додається 5. Тепер мені потрібно скопіювати 3і замінити його nextполе для посилання на 4копію, але тепер 2посилається на старе 3...

Або іншими словами, щоб зробити додавання, весь список, здається, потрібно скопіювати.

Мої запитання:

• Чи правильно моє мислення? Чи є спосіб зробити додавання, не копіюючи всю структуру?

• Мабуть, "Ефективна Java" містить рекомендації:

  Заняття повинні бути незмінними, якщо немає дуже вагомих причин зробити їх незмінними ...

  Це хороший випадок для змінності?

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

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

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

Як приклад того, чому попередньо не потрібно копіювати весь список, розгляньте, що у вас є:

2 -> 3 -> 4

Попередня подача 1дає вам:

1 -> 2 -> 3 -> 4

Але зауважте, що не має значення, чи хтось ще досі має посилання на 2голову свого списку, оскільки цей список незмінний, а посилання йдуть лише в одну сторону. Немає способу сказати, що 1існує, навіть якщо ви маєте лише посилання на нього 2. Тепер, якщо ви додали 5до будь-якого списку, вам доведеться зробити копію всього списку, бо в іншому випадку він також з’явиться в іншому списку.

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

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

Тому я пропоную вам подумати: чи хочете ви ефемерний інтерфейс чи стійкий? Чи більшість операцій створює новий список і залишає немодифіковану версію доступною (стійкою), або ви пишете такий код (ефемерний):

list.append(x);
list.prepend(y);

Обидва варіанти є чудовими, але реалізація повинна відображати інтерфейс: стійка структура даних отримує вигоду з незмінних вузлів, тоді як ефемерна потребує внутрішньої зміни, щоб реально виконати обіцянки продуктивності, які вона неявно дає. java.util.Listта інші інтерфейси є ефемерними: реалізація їх у незмінному списку є недоцільною та фактично загрожує продуктивності. Хороші алгоритми на змінних структурах даних часто сильно відрізняються від хороших алгоритмів на незмінних структурах даних, тому одягання незмінної структури даних як змінна (або навпаки) запрошує погані алгоритми.

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

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

Функціональні мови, такі як prolog та haskel, забезпечують прості способи отримати передній елемент та іншу частину масиву. До зворотного боку - операція O (n) з копією кожного вузла.

Як зазначали інші, ви впевнені, що незмінний однозв'язаний список вимагає копіювання всього списку під час виконання операцій додавання.

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

Переліки відмінностей (див., Наприклад, тут ) є цікавою альтернативою. Список різниць завершує список і забезпечує операцію додавання в постійний час. Ви в основному працюєте з обгорткою стільки, скільки вам потрібно буде додати, а потім перетворите назад у список, коли закінчите. Це якимось чином схоже на те, що ви робите, коли використовуєте a StringBuilderдля побудови рядка, і в кінці отримуєте результат у вигляді String(незмінного!) Виклику toString. Одна відмінність полягає в StringBuilderтому, що a є змінним, але список різниць є незмінним. Крім того, коли ви перетворюєте список різниць назад у список, вам все одно доведеться побудувати весь новий список, але, знову ж таки, вам потрібно це зробити лише один раз.

Реалізувати незмінний DListклас, який забезпечує аналогічний інтерфейс, як Haskell, має бути досить простим Data.DList.

Ви повинні подивитися це чудове відео з 2015 року React conf, створене творцем Immutable.js Лі Байроном. Це дасть вам покажчики та структури, щоб зрозуміти, як реалізувати ефективний незмінний список, який не дублює вміст. Основні ідеї: - поки два списки використовують однакові вузли (те саме значення, той самий наступний вузол), той самий вузол використовується, - коли списки починають відрізнятися, на вузлі розбіжності створюється структура, яка містить покажчики на наступний конкретний вузол кожного списку

Це зображення з навчального посібника може бути чіткішим, ніж моя зламана англійська:

Це не суто Java, але я пропоную вам прочитати цю статтю про незмінну, але стійку структуру даних, проіндексовану виконавцем, написану в Scala:

http://www.codecommit.com/blog/scala/implementing-persistent-vectors-in-scala

Оскільки це структура даних Scala, її можна використовувати і на Java (дещо більше деталізації). Він заснований на структурі даних, доступній в Clojure, і я впевнений, що є ще "рідна" бібліотека Java, яка пропонує її.

Крім того, примітка про побудову незмінних структур даних: те, що вам зазвичай потрібно, - це якийсь тип "Builder", який дозволяє "мутувати" свою структуру даних "недобудови", додаючи до неї елементи (в межах одного потоку); після завершення додавання ви викликаєте метод на об'єкт "недобудований", такий як .build()або .result(), який "будує" об'єкт, надаючи вам незмінну структуру даних, якою ви можете безпечно ділитися.

Підходом, який іноді може бути корисним, було б мати два класи об'єктів, що містять список - об'єкт списку вперед-переліку з finalпосиланням на перший вузол у списку, пов'язаному вперед, і початково-нульовий не- finalпосилання, який (коли не -null) ідентифікує об’єкт зворотного списку, що містить ті самі елементи в протилежному порядку, і об'єкт зворотного списку з finalпосиланням на останній елемент списку, пов'язаного з зворотним зв'язком, і початково-нульовий не остаточний посилання, який (коли не -null) ідентифікує об'єкт списку вперед, що містить ті самі елементи в протилежному порядку.

Попередження пункту до списку переадресації або додавання елемента до зворотного списку просто вимагатиме створення нового вузла, який посилається на вузол, ідентифікований finalпосиланням, та створення нового об'єкта списку того ж типу, що і оригінал, із finalпосиланням до цього нового вузла.

Для додавання елемента до списку переадресації або передпресування до зворотного списку потрібно мати список іншого типу; Перший раз, коли це робиться з певним списком, він повинен створити новий об'єкт протилежного типу та зберігати посилання; повторення дії має повторно використовувати список.

Зауважте, що зовнішній стан об'єкта списку вважатиметься однаковим, незалежно від того, чи є його посилання на список протилежного типу нульовим чи ідентифікує список протилежного порядку. Не потрібно створювати змінних final, навіть коли використовується багатопотоковий код, оскільки кожен об'єкт списку матиме finalпосилання на повну копію його вмісту.

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