Знайомство з серіалізацією

1. Вступ

Уявіть, що ваш обʼєкт у програмі — це складний, красивий конструктор LEGO. Він складається з безлічі деталей, кожна на своєму місці, і все це разом утворює єдине ціле. Поки конструктор стоїть у вас на столі (у памʼяті компʼютера), усе чудово. Але що, якщо треба перевезти його до друга (передати мережею) або просто прибрати в коробку до наступного разу (зберегти на диск)? Ви ж не можете просто взяти й покласти його в плоску коробку — він розсиплеться!

Ось цим — акуратним розбиранням обʼєкта на частини для безпечного зберігання або передавання — і займається серіалізація. Це процес перетворення вашого обʼєкта з його «живого» стану в памʼяті на послідовність байтів (або текстове подання), яку можна зберегти у файл, передати мережею чи помістити в буфер обміну. Фактично це як акуратно розібрати ваш конструктор LEGO, скласти всі деталі в пакети, підписати їх і запакувати в коробку для транспортування або зберігання.

flowchart LR
    ObjectInMemory(Обʼєкт у памʼяті)
    Serialize[СЕРІАЛІЗАЦІЯ]
    BytesOrText[Байти / Текстовий файл / JSON / XML]
    Deserialize[ДЕСЕРІАЛІЗАЦІЯ]
    ObjectAgain(Обʼєкт знову в памʼяті)

    ObjectInMemory -->|serialize| Serialize
    Serialize --> BytesOrText
    BytesOrText -->|deserialize| Deserialize
    Deserialize --> ObjectAgain

І, звісно, якщо ми щось запакували, потрібно вміти це розпакувати. Зворотний процес називається десеріалізацією. Це коли ви берете цю коробку з пакетиками деталей LEGO, висипаєте їх, а потім, дотримуючись інструкцій (або просто памʼятаючи, як це було зібрано), відновлюєте обʼєкт у памʼяті в точно такому самому стані, у якому він був до пакування. Ось так, магія!

Термін «серіалізація» буквально означає «послідовне подання». Ми беремо складну, можливо, розкидану в памʼяті структуру (обʼєкт може посилатися на інші обʼєкти, колекції тощо, утворюючи цілий «граф обʼєктів») і перетворюємо її на лінійну, послідовну форму, яку легко записати або передати.

2. Чому недостатньо просто File.WriteAllText?

Чудове запитання! Якби всі дані були простими рядками чи числами, ми б обійшлися без серіалізації. Але в реальному світі наші застосунки працюють зі складними моделями: клієнти, замовлення, товари, студенти, герої, рівні. Усі вони представлені обʼєктами в памʼяті. І ось чому серіалізація — ваш найкращий друг:

Збереження стану застосунку

Уявіть, що ви створюєте текстовий редактор. Користувач набирає текст, змінює шрифти, вставляє зображення. Усі ці дані (текст, налаштування, позиція курсора) — це, по суті, обʼєкти у вашій програмі. Коли користувач натискає «Зберегти», ви хочете, щоб під час наступного запуску програми він побачив усе саме так, як залишив. Серіалізація дає змогу «заморозити» всі потрібні обʼєкти й записати їх на диск, а потім «розморозити» під час завантаження. Це як функція «Зберегти гру» у відеоіграх. Адже ви не захочете знову проходити весь рівень, якщо раптом вимкнули світло.

Обмін даними між застосунками

Ваша програма на C# спілкується з веб‑сервером, який може бути написаний на Python. Або ваш мобільний застосунок (наприклад, на Xamarin чи MAUI) взаємодіє з сервером на .NET. Ці програми не мають спільної памʼяті. Щоб обмінятися даними, їм потрібен спільний, зрозумілий формат. Серіалізація перетворює обʼєкти в такий універсальний формат (наприклад, JSON або XML), який можна передати мережею. На іншому кінці приймальна сторона десеріалізує ці дані назад у свої обʼєкти, зрозумілі для їхньої мови програмування. Без серіалізації довелося б вручну «розпаковувати» кожен шматочок даних і збирати його назад. Це було б довго, нудно і дуже схильно до помилок!

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

Конфігурація застосунку

Часто застосунки мають безліч налаштувань: розмір вікна, шлях до файлів, нещодавно відкриті документи, колірна схема. Зберігати кожне налаштування в окремій змінній, а потім вручну записувати їх у файл налаштувань (наприклад, .ini або .txt) — неефективно й незручно. Значно простіше визначити клас НалаштуванняЗастосунку, де кожне налаштування — це властивість, а потім просто серіалізувати весь цей обʼєкт налаштувань у файл. Під час запуску програми — десеріалізувати. Краса!

Кешування даних

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

3. Основна ідея: збереження «стану»

Найважливіша концепція в серіалізації — це збереження стану. Обʼєкт, по суті, — це сукупність своїх полів і їхніх значень у певний момент часу. Серіалізація «фотографує» цей стан. Коли ми десеріалізуємо обʼєкт, ми не просто створюємо новий порожній екземпляр, а відтворюємо його з усіма тими значеннями полів, які він мав на момент серіалізації.

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

Класичний приклад: серіалізація улюбленців

Продовжімо розвивати наш застосунок «Енциклопедія улюбленців». Припустімо, у нас є ось такий клас:

public class Pet
{
    public string Name { get; set; }
    public string Type { get; set; } // Наприклад: «Кіт», «Собака»
    public int Age { get; set; }
}

Ми хочемо:

• Заповнити колекцію таких обʼєктів у памʼяті,
• Зберегти її у файл,
• А пізніше відновити (наприклад, після перезапуску програми).

Схематично це виглядає так:

Колекція List<Pet>
    ↓ серіалізація
    Файл (JSON, XML, байти)
    ↓ десеріалізація
Колекція List<Pet> (знову в памʼяті!)

4. Які бувають формати серіалізації

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

Поки що не вдаватимемося в деталі — просто запамʼятайте кілька назв, щоб розуміти, про що йтиметься в наступних лекціях:

• JSON (JavaScript Object Notation): нині це, мабуть, найпопулярніший формат. Він текстовий, відносно легко читається людиною і широко використовується для обміну даними у вебі. Виглядає як пари «ключ — значення», взяті у фігурні дужки. По суті, це звичайний текст, але структурований так, що його легко парсити програмам.
• XML (Extensible Markup Language): старіший, але досі дуже поширений текстовий формат. Він заснований на тегах, як HTML, і має сувору структуру. Його часто використовують для конфігураційних файлів і обміну даними в корпоративних системах. Він теж читається людиною, але часто буває «багатослівним».
• Бінарні формати: ці формати зберігають дані не у вигляді тексту, а безпосередньо у вигляді байтів, як вони зберігаються в памʼяті. Вони зазвичай компактніші й швидші для серіалізації/десеріалізації, але зовсім нечитабельні для людини. Їх використовують там, де важлива максимальна продуктивність або мінімальний розмір файлу, наприклад, для збереження ігрових даних або для передавання великих обсягів інформації між власними компонентами системи.

Вибір формату залежить від завдання: чи потрібно, щоб людина могла легко прочитати дані? Чи важливі швидкість і розмір? На які платформи ви передаєте дані? Для обміну між різними системами JSON і XML часто є пріоритетними через їхню універсальність. Для збереження даних усередині однієї й тієї самої програми бінарні формати можуть бути швидшими й ефективнішими.

Серіалізація — це потужний інструмент, який лежить в основі багатьох сучасних застосунків. Вона дає змогу нашим програмам «памʼятати» свої дані між запусками, спілкуватися між собою та ефективно керувати складною інформацією. У наступних лекціях ми вже не просто говоритимемо про «магію», а навчимося застосовувати її самостійно, використовуючи бібліотеки .NET. Приготуйтеся — буде цікаво!