Існують всілякі суміші. У вас є структури даних, які не пов'язані з алгоритмами, алгоритмами, які не потребують (реальних) структур даних, але найчастіше ці два є в одному пакеті.
Редагувати: як правильно вказав @Doval, структури даних самі по собі не мають жодних операцій, пов'язаних з ними. Акт поєднання структури даних та алгоритму формує абстрактний тип даних.
Структури даних без алгоритмів
Розглянемо для прикладу структуру даних для зберігання двовимірних координат, відповідно названих Point. З точки зору алгоритмів нічого не можна зробити для точки, і це дійсно просто контейнер для xі yзначення. Звичайно, надаючи цю структуру даних, тепер ви можете додавати всілякі алгоритми поверх неї (обчислення відстані, опуклі корпуси, що-у вас є).
Можна придумати безліч структур даних, які є просто нагромадженням окремих даних. Хоча вони трапляються часто на практиці, вони не приносять хорошого навчального матеріалу, оскільки з цього нічого не можна дізнатися, як тільки ви зрозуміли, що окремі елементи даних можуть накопичуватися в новій структурі даних (наприклад, що ви дізнаєтесь після наведеного вище Pointприкладу, якщо я надаю вам таку дивовижну структуру даних Point3D, яку називають , яка може зробити те ж саме для тривимірного простору?)
Алгоритми без (реальних) структур даних
"Справжній", оскільки, очевидно, кожен цікавий алгоритм потребує примітивних типів даних, таких як цілі чи булеві, і ми не хочемо розглядати їх як структури даних у цьому контексті. Як і вище, ці алгоритми, як правило, досить прості. Зокрема, вони не мають будь-якого складного стану, оскільки це зазвичай переходить у структуру даних (див. Наступний розділ).
Прикладом такого алгоритму може бути обчислення найбільшого спільного дільника на два числа. Алгоритми Евкліда для gcd дійсно потребують лише вміщення двох цілих чисел та маніпулювання ними.
Як тільки речі стають цікавішими, ви дуже скоро входите у світ абстрактних типів даних. Наприклад, сито Ератостена засноване на масиві. Зараз ми можемо обговорити, чи масив все ще примітивний, чи насправді ви можете обговорити, якщо ціле число ще не є структурою даних. Так чи інакше, алгоритми, які існують повністю без структур даних, є досить нудними, навіть якщо ви погоджуєтесь з їх окремим існуванням.
Алгоритми поєднуються зі структурами даних, відомими також абстрактними типами даних
Зараз це цікаві, але з двох дуже різних причин. Зазвичай до них можна звернутися з двох напрямків: спочатку структура даних або спочатку алгоритм.
У той час як абстрактний тип даних визначається комбінацією структури даних + алгоритмів / операцій, ми часто переглядаємо їх з акцентом на будь-який з них і вважаємо інший можливим.
Структура даних, потім алгоритм
Ви зустрінете абстрактні типи даних, які досить прості у використанні, але залучають більш-менш складні алгоритми, щоб змусити їх працювати всередині країни. Наприклад, використання HashMapтривіальне, але передбачає чудову хеш-функцію та вирішення хеш-колізій зсередини. Тим не менш, з вашого погляду, як користувача, ви дбаєте про це як про щось, що зберігає для вас дані, а не те, що щось робить для вас.
На відміну від останньої групи нижче, ці структури даних не піддають своїх користувачів цим алгоритмам. Вам не потрібно знати і не дбати про HashMapвнутрішню хеш-функцію, щоб мати можливість її використовувати. (Хоча ефективно використовувати це, можливо, ви захочете знати ці речі;)
Алгоритм, потім структура даних
Інший напрям означає, що у вас є алгоритм, який ви хочете мати можливість просто використовувати, але який потребує внутрішньої структури даних, щоб він працював за призначенням. Прикладом може бути алгоритм розподілу бінарного простору (BSP), який ви можете просто запитати для двовимірного Pointвеликого набору точок, найближчого до заданої точки запиту. Однак вам потрібна структура дерева (і навіть додаткові алгоритми, такі як обчислення відстані) зсередини, щоб насправді написати алгоритм.
Загалом, можна сказати, що алгоритми цієї групи використовують задіяні структури даних для їх внутрішнього представлення стану. Я заперечую, що ця група алгоритмів є найрізноманітнішою, і ви знайдете безліч різноманітних, які відповідають цій загальній схемі. Щодо точки зору, ми вважаємо це цікавим, оскільки вони щось роблять (сортування за допомогою f.ex.) для нас, і не так сильно піклуються про частину даних, що містять дані.
Тісно пов’язані структури даних та алгоритми
Нарешті, у вас є структури даних, які дуже близькі до алгоритмів, які безпосередньо відповідають їм. Типовим прикладом є двійкове дерево, яке, коли ви хочете зробити з ним щось значуще, змушує на вас тему алгоритмів ходіння по деревах (глибина-перше, ширина-перше, що завгодно).
У цих випадках ми так часто змінюємо фокус нашого погляду на результуючі абстрактні типи даних. Іноді ви дбаєте про структуру вашого дерева, через кілька хвилин ви дбаєте про те, чи зможете виконати операцію пошуку на ньому, тоді ви замислюєтесь про те, щоб видалити вузол, і відразу про те, як виглядає структура після цього. Хоча все це справедливо і для інших вищезазначених розділів, це не те, що є основним у вашій увазі, наприклад, коли ви зберігаєте / отримуєте дані в / з Mapабо під час сортування пов'язаного списку.