Перейти до вмісту

Abstraction

Матеріал з K2 ERP Wiki
Версія від 09:46, 9 травня 2026, створена R (обговорення | внесок) (Створена сторінка: {{SEO |title=Abstraction — абстракція в програмуванні, інформатиці, ООП, API, архітектурі й мисленні |description=Abstraction — Wiki-стаття про абстракцію як принцип спрощення складних систем через приховування деталей і виділення суттєвого. Розглянуто абстракцію в програму...)
(різн.) ← Попередня версія | Поточна версія (різн.) | Новіша версія → (різн.)

}

Приклади:

Спочатку зрозуміймо 2-3 реальні сценарії, а потім виділимо спільну модель.

як приклад, якщо код залежить від інтерфейсу `EmailSender`, у тесті можна підставити fake реалізацію:

критично: хороший рівень абстракції приховує деталі, але не приховує важливі обмеження. Слово “дерево” не виступає як конкретним деревом. Приклад:

process(data: any) {
// complex storage logic
Перевага: абстракція дає можливість будувати великі системи з менших зрозумілих частин.
charge(amount: number): Promise<void>;

</syntaxhighlight>

Абстракція зустрічається в:

const total = price + tax;

Приклад: База даних — потужна абстракція над фізичним зберіганням даних. Проста аналогія: карта — це абстракція території. info(message: string): void;

  • presentation layer;
  • application layer;
  • domain layer;
  • infrastructure layer;
  • data access layer;
  • integration layer;
  • API layer.== Абстракція і безпека ==

Головна думка: абстракція — це не втеча від деталей, а спосіб керувати ними. * головну ідею;

  • базовий приклад;
  • типові сценарії;
  • обмеження;
  • деталі за потреби;
  • troubleshooting;
  • API reference. const user = await prisma.user.findUnique({

interface Logger {

Абстракція і Domain Model

Абстракція в Docker

const price = 100; Коли користувач системи бачить:

== Абстракція і типи ==

Зробімо універсальний компонент для всього, що здатна колись знадобитися. Тому критично знати хоча б основи рівня нижче.<syntaxhighlight lang="text">
'''Проста ідея:''' якщо блок коду має зрозумілу назву й повторюється, його часто варто перетворити на абстракцію. Але не кожна абстракція має бути максимально універсальною. }

'''критично:''' іноді найкраща абстракція  це поки що не створювати абстракцію.== Абстрактний клас ==

== Див. так само ==

interface PaymentProvider {

SQL-запити

* Pod;
* Deployment;
* Service;
* ConfigMap;
* Secret;
* Ingress;
* PersistentVolume;
* Namespace;
* Job;
* StatefulSet. users.append("Oleh")

== Абстракція файлової системи ==
</div>

</syntaxhighlight>

Практична роль: функція дає назву дії й ховає деталі її виконання.

Загальний SEO-опис

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

</syntaxhighlight>

console.log(item);

class ReportService {

}

}

Абстракція і продуктивність

як приклад, domain layer не має знати, чи інформаційні дані зберігаються в PostgreSQL, MongoDB або файлі. API — це одна з найважливіших форм абстракції в програмуванні. Вона не прибирає складність із реальності, але оптимізує людині працювати з нею по шматках. class DataManager {

return pdf;

def send_welcome_email(user): </syntaxhighlight>

Абстракція в мережах

<syntaxhighlight lang="typescript">
Приклади:

Так само слова:

  • число як абстракція кількості;
  • змінна як абстракція значення;
  • функція як абстракція залежності;
  • вектор як абстракція напрямку й величини;
  • група як абстракція симетрії;
  • граф як абстракція зв’язків;
  • множина як абстракція колекції об’єктів. Код, який викликає функцію, не мусить знати, як формується лист.

Абстракція і залежності

 name: string;
const stringValue = first(["a", "b", "c"]);
</div>

 }

function first<T>(items: T []): T | undefined {

'''Критично:''' абстракція не має створювати фальшиве відчуття безпеки. type UserId = string;
 }
як приклад, sorting algorithm описує ідею впорядкування, не привязуючись до конкретної таблиці, файлу або UI. Приклади:

'''Практична роль:''' файл  одна з найуспішніших абстракцій в історії компютерів.
Тепер бізнес-логіка залежить від абстракції, а не від конкретного Stripe SDK.

Приклад: </syntaxhighlight>

Головна причина існування абстракції — складність. Приклади:

// Stripe-specific logic
  • Factory приховує створення об’єктів;
  • Adapter приховує різницю між інтерфейсами;
  • Facade дає простий інтерфейс до складної системи;
  • Strategy дає можливість замінювати алгоритми;
  • Repository приховує доступ до даних;
  • Observer приховує механізм повідомлень;
  • Decorator додає поведінку без зміни основного об’єкта. Практична роль: назва абстракції має зменшувати кількість питань, а не створювати нові. Замість ручного запуску контейнерів користувач системи описує бажаний стан.== Leaky Abstraction ==

docker run my-app

Шкодить, коли:

Практична роль: функціональні абстракції часто дозволяють писати код ближче до опису перетворення даних.

Практична роль: AI-система не функціонує з “сенсом” так, як людина, а з абстрактними представленнями даних. Краще: Кращий підхід:

const activeUserEmails = users

! Сильна абстракція робить систему зрозумілішою, тестованішою й гнучкішою.</syntaxhighlight>

конкурентні переваги абстракції

SELECT name FROM users WHERE id = 42;

Практична роль: рефакторинг — це не тільки “прибрати дублювання”, а й знайти правильні межі абстракцій. Функція — одна з найпростіших форм абстракції. type User = {

</syntaxhighlight> Цікавий момент: хороша domain abstraction часто важливіша за вибір framework, бо вона визначає, як команда думає про ERP-продукт. Internet layer: IP API приховує: Таблиці й рядки

Джерела

Цікавий факт: програмування багато взяло з математичної абстракції: функції, типи, структури даних, графи, логіку й формальні моделі. клієнт ERP не знає, як саме сервер знаходить користувача: через PostgreSQL, кеш, мікросервіс або інший механізм.
}

</syntaxhighlight>

ORM або Object-Relational Mapping — це абстракція, яка дає можливість працювати з базою даних через об’єкти або моделі.

Абстракція має ризики. console.log("Hello");

Практична роль: компонент — це коробка з написом, де зовні видно призначення, але не всі внутрішні дроти. Тому головне задача розробника — не без зусиль створювати абстракції, а вибирати правильний рівень абстракції для конкретної задачі.

Абстракція і модульність

Link layer: Ethernet, Wi-Fi

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

};

</syntaxhighlight>

Критично: усі нетривіальні абстракції можуть протікати.== Абстракція і рефакторинг == Domain model — це абстракція предметної області. * базу даних;

  • внутрішню архітектуру;
  • алгоритми;
  • сторонні сервіси;
  • authentication logic;
  • validation;
  • business rules;
  • storage details. Користувачу не потрібно бачити всі внутрішні кроки. Інтерфейс користувача — це абстракція над діями системи. const pdf = await this.renderPdf(data);

Чи стане код простішим для користувача? критично: не варто боятися абстракцій через performance наперед. }

Абстракція і функціональне програмування

// clear domain logic

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

describe(): string {

У програмуванні ці слова часто стають назвами класів, таблиць, функцій і модулів. Абстракції часто створюють для reuse. private async renderPdf(data: unknown) { GET /api/users/42

Приклади: |- | Abstraction | Виділяє головне й приховує несуттєве | `sendEmail(user)` замість деталей SMTP |- | Encapsulation | Ховає внутрішній стан і захищає доступ до нього | private fields у класі |}

Проста ідея: facade — це “одна зрозуміла двері” до кімнати, де всередині багато механізмів. Погані назви:

Практична роль: design patterns — це не магічні рецепти, а перевірені способи керувати залежностями й абстракціями.

Приклад checklist для створення абстракції

return Math.PI * this.radius * this.radius;
}

Абстракція в базах даних

sent: string [] = [];

Абстракцію варто створювати, коли: Абстракція здатна мати performance cost. компонент приховує внутрішню реалізацію й відкриває тільки потрібний інтерфейс. return `Area: ${this.area()}`;

return items [0];

Interface здатна визначати:

}

users = []

  • функції;
  • loops;
  • callbacks;
  • promises;
  • async/await;
  • iterators;
  • generators;
  • event handlers;
  • workflows;
  • pipelines. Facade створює простий інтерфейс до складної підсистеми.

Interface

async generateMonthlyReport(month: string) {

Абстракція в API

}

Абстракції можуть полегшувати тестування. Абстрактний клас дає можливість описати спільну ідею, але залишити частину поведінки конкретним класам.</syntaxhighlight>

Абстракція відповідає на питання: “Який простий інтерфейс ми даємо?” Ознаки: Ознаки надмірної магії:

 area(): number {
== Under-abstraction ==
Кнопка “Оплатити” приховує:

як приклад:

Типові кроки:
== Абстракція в операційних системах ==
Багато design patterns виступає як способами створення абстракцій. Якщо назва нічого не пояснює, абстракція слабка. '''Control abstraction''' — це приховування деталей керування потоком виконання. У програмуванні абстракція дає можливість викликати функцію, використовувати клас, працювати з API, відкривати файл, надсилати HTTP-запит або робити SQL-запит без потреби кожного разу думати про байти, пам’ять, сокети, драйвери, протоколи й фізичне зберігання даних. Абстракція здатна допомагати безпеці або шкодити їй. private async saveFile(pdf: unknown) {
</div>
<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
const numberValue = first([1, 2, 3]);
class InvoiceCalculator {

== Абстракція і складність ==

'''критично:''' мережеві абстракції зручні, але при проблемах іноді потрібно спускатися нижче: DNS, TLS, TCP, firewall, routing.<div style="background:#f0eaff; border-left:6px solid #8e44ad; padding:12px; margin:12px 0;">
</div>
}
Чи виступає як реальне повторення або варіації? subject = "Welcome"

class Circle extends Shape {

<syntaxhighlight lang="text">

Абстракція в математиці

Encapsulation і abstraction часто плутають. Файлова платформа дає можливість працювати з іменами, папками й файлами замість фізичних деталей накопичувача.== Правильний рівень абстракції ==

Погано:

Документація так само використовує абстракцію. користувач системи сервісу викликає `generateMonthlyReport`, а не керує всіма деталями. Коли браузер відкриває сайт, користувач системи бачить URL, але за ним стоїть DNS, TCP, TLS, HTTP, routing і багато іншого. * яка предметна область;
* що робить клас;
* які інформаційні дані приймає;
* який результат повертає. * `calculateInvoiceTotal`;
* `sendPasswordResetEmail`;
* `createOrder`;
* `validatePaymentMethod`;
* `parseCsvFile`;
* `UserRepository`;
* `PaymentGateway`.<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
він не думає про:
}

'''критично:''' поганий код здатна бути поганим і через надлишок абстракції, і через її нестачу. Якщо API небезпечний у неправильному використанні, це потрібно явно документувати. Database engine читає інформаційні дані
Backend обробляє запит
</div>
== Абстракція в хмарних сервісах ==

 const data = await this.loadData(month);
Абстракція настільки звична, що люди часто не помічають її. abstract class Shape {
print(users [0])
Приклади:
<syntaxhighlight lang="typescript">
'''Abstract class'''  це клас, який задає спільну структуру, але не завжди має повну реалізацію. * список приховує внутрішній масив;
* словник приховує hash table;
* обєкт `User` приховує структуру полів;
* database table приховує фізичне розміщення даних;
* ORM model приховує частину SQL-запитів;
* collection API приховує спосіб обходу елементів. Це трапляється, коли вона робить багато прихованих дій без очевидного пояснення. // unclear logic

* автомобіль має кермо, педалі й важіль передач, але водій не керує кожним клапаном двигуна;
* банкомат показує зняти гроші, але приховує мережевий обмін із банком;
* телефонна кнопка подзвонити приховує радіозвязок, мережеву маршрутизацію й протоколи;
* карта міста приховує реальні будинки, дерева, бордюри й дроти, залишаючи дороги й орієнтири;
* меню в ресторані приховує бізнес-процес закупівельна діяльність, готування й логістику кухні.</div>
Ці поняття не виступає як без зусиль таблицями або JSON-обєктами. Реалізації можуть бути різними:

}

* приховувати нестабільні деталі;
* мати зрозумілу назву;
* відповідати реальній моделі;
* не бути занадто загальною;
* не бути занадто вузькою;
* мати корисний інтерфейс;
* зменшувати складність;
* не створювати зайву магію;
* бути тестованою;
* не приховувати важливі обмеження.== Абстракція і Design Patterns ==
== Абстракція в UI/UX ==
}

Repository функціонує з базою

Хороша абстракція має правильний рівень. * Найкращі абстракції часто здаються “очевидними”, бо добре приховують складність. * sort;

  • search;
  • map;
  • reduce;
  • filter;
  • shortest path;
  • hashing;
  • caching;
  • retry;
  • backoff;
  • pagination. * `doStuff`;
  • `processData`;
  • `handleThing`;
  • `Manager`;
  • `Helper`;
  • `Service2`;
  • `CommonUtils`. * виступає як лише один простий випадок;
  • майбутні сценарії невідомі;
  • код і так зрозумілий;
  • абстракція не має хорошої назви;
  • вона приховує важливі обмеження;
  • вона створює більше файлів, ніж сенсу;
  • вона потрібна лише “бо так архітектурно красиво”;
  • вона ускладнює debugging;
  • команда не розуміє її призначення. Поняття
}

</syntaxhighlight>

Абстракція в архітектурі ПЗ

});

return price + tax;
Кожен рівень приховує деталі нижчого рівня й надає простіший інтерфейс вищому рівню. Це модель того, як бізнес-середовище розуміє свою реальність.

Кращі назви: </syntaxhighlight> Практична порада: якщо ви вже двічі написали схожий код і бачите третій реальний випадок, можливо, час для абстракції. Окремо варто відзначити інтерфейси, поняття й шари, які приховують внутрішні деталі і залишають користувачу або розробнику зрозумілий спосіб взаємодії. * Документація щодо operating systems, databases, APIs, networking, Docker, Kubernetes і cloud computing. У програмуванні абстракція дає можливість приховати складну реалізацію за простим інтерфейсом. Вона не показує все, але показує те, що потрібно для руху. * функція приховує послідовність дій;

  • клас приховує стан і поведінку;
  • API приховує внутрішню логіку сервісу;
  • бібліотека приховує складні алгоритми;
  • база даних приховує фізичне зберігання даних;
  • операційна платформа приховує hardware;
  • framework приховує типову інфраструктурну логіку;
  • ORM приховує частину SQL-роботи;
  • container приховує деталі середовища запуску. body = f"Hello, {user ['name']}!"

Висновок

Приклади:
Назва  важлива частина абстракції. * приховує небезпечні defaults;
* створює ілюзію безпеки;
* не показує межі доступу;
* не дає можливість зрозуміти, де перевіряються права;
* маскує SQL injection або command injection ризики. '''Практична роль:''' data abstraction дає можливість працювати з користувачем, замовленням або списком, а не з байтами й адресами памяті. Погана документація або занадто абстрактна, або тоне в деталях. * Абстракції часто народжуються з повторення, але вмирають від надмірної універсальності. '''Практична роль:''' через абстракції розробник здатна використовувати складну можливість через простий виклик.== Типові помилки початківців ==
Індекси
Frontend викликає API
Чи можна її протестувати? class FakeEmailSender {
== Абстракція і інкапсуляція помилок ==
Код застосунку функціонує з `UserRepository`, а не з SQL-запитами в кожному controller.<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

Людська мова сама виступає як системою абстракцій. '''Over-abstraction'''  це надмірна абстракція, коли код стає складнішим через зайві інтерфейси, шари й узагальнення. Якщо вона робить усе заплутанішим, це погана абстракція.<syntaxhighlight lang="text">

=== UI component ===
=== Cloud storage abstraction ===
== Абстракція в ООП ==
== Абстракція і тестування ==

'''Практична роль:''' хмарна інфраструктура часто продає не сервер, а абстракцію над сервером.== Рівні абстракції ==

Транзакції
<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
== Абстракція в Kubernetes ==

<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

== Цікавий факт ==

=== Payment gateway ===

* pointer як абстракція адреси;
* struct як абстракція layout даних;
* system call як абстракція доступу до ядра;
* driver API як абстракція hardware;
* memory allocator як абстракція виділення памяті. У штучному інтелекті абстракція застосовується для для представлення складної реальності у вигляді моделей.<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

'''критично:''' абстрактний клас корисний, коли виступає як спільна логіка.<syntaxhighlight lang="typescript">

Приклад:

'''Найлюдяніший факт:''' абстракція  це спосіб не потонути в деталях.<syntaxhighlight lang="typescript">

<syntaxhighlight lang="typescript">

* зменшує складність;
* покращує читабельність;
* приховує деталі реалізації;
* полегшує повторне використання;
* дає можливість змінювати реалізацію;
* покращує тестування;
* оптимізує модульності;
* створює зрозумілі API;
* дає можливість працювати на вищому рівні;
* оптимізує командній розробці;
* зменшує дублювання;
* підтримує архітектурні межі;
* робить систему більш керованою. const user = await userRepository.findById(id);
== Цікаві факти про абстракцію ==

Алгоритм  це абстракція над процесом розвязання задачі. class StripePaymentProvider implements PaymentProvider {

 }
== Приклади сценаріїв використання ==
Приклади:

<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

Cloud computing активно використовує абстракції.</div>

<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
'''Помилка:''' абстрагувати все наперед. Спрощено:
Можливі проблеми:
Приклад:
== Абстракція і назви ==

== ORM як абстракція ==
</div>
Приклад:

'''Практична роль:''' типи роблять абстракції видимими для компілятора й редактора коду.<div style="background:#fef2f2; border-left:6px solid #ef4444; padding:12px; margin:12px 0;">

'''Цікавий факт:''' SQL  це дуже сильна абстракція: розробник описує, які інформаційні дані потрібні, а database engine вирішує, як їх знайти. Kubernetes створює абстракції над контейнерами й інфраструктурою. charge(amount: number): Promise<void>;

Physical layer: сигнали, радіохвилі, кабелі
Абстракція застосовується для для зменшення складності. '''Основна ідея:''' абстракція  це спосіб сказати: Мені критично, що це робить, а не всі деталі того, як саме це зроблено. Розробник здатна запустити:

 where: { id: 42 }

і не встановлювати вручну всі залежності на host. Тут код говорить:

Операційна платформа  це великий набір абстракцій над hardware. користувач системи списку не думає про те, як Python виділяє память і змінює розмір внутрішнього масиву.=== Repository layer ===
</div>

Приклад для web-застосунку:

{{SEO
|title=Abstraction  абстракція в програмуванні, інформатиці, ООП, API, архітектурі й мисленні
|description=Abstraction  Wiki-стаття про абстракцію як принцип спрощення складних систем через приховування деталей і виділення суттєвого. Розглянуто абстракцію в програмуванні, інформатиці, ООП, API, функціях, класах, інтерфейсах, базах даних, операційних системах, мережах, архітектурі ПЗ, дизайні, математиці, мисленні, переваги, ризики, приклади, цікаві факти і хороші практики.
|keywords=Abstraction, абстракція, abstraction in programming, програмна абстракція, computer science, software engineering, OOP, API, interface, encapsulation, class, function, data abstraction, control abstraction, database abstraction, operating system abstraction, network abstraction, architecture, design patterns, software design
|alternativeTo=ручне керування всіма деталями; дублювання коду; прямий доступ до низькорівневих механізмів; hardcoded logic; tightly coupled design; spaghetti code; робота без API; робота без інтерфейсів; складні системи без шарів; реалізація без моделі; хаотичний код без розділення відповідальностей
}}

Що саме вона приховує? Якщо потрібен лише контракт, interface часто простіший. '''Abstraction'''  це один із фундаментальних принципів інформатики й програмування. Без абстракції:

* методи;
* параметри;
* типи;
* очікувану поведінку;
* контракт між частинами системи.<div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">
'''Практична роль:''' control abstraction дає можливість описувати намір, а не кожен механічний крок. Функції, класи, API, бази даних, операційні системи, мережеві протоколи, Docker, Kubernetes і навіть UI-кнопки  усе це приклади абстракцій. '''Interface'''  це SEO-опис того, що обєкт або компонент вміє робити, без обовязкового розкриття того, як саме. Воно означає, що абстракції ближчі до hardware і мають менше прихованого запасу.</div>
== Абстракція і low-level програмування ==
 }
Вона повинна:
! Хороша абстракція часто народжується після того, як повторення й варіації вже стали видимими.</div>

* багато класів без реальної потреби;
* інтерфейс має лише одну реалізацію й не планується друга;
* простий код розкиданий по багатьох файлах;
* важко знайти, де реально виконується дія;
* назви дуже загальні: Manager, Handler, Processor, Service;
* потрібно відкрити 10 файлів, щоб зрозуміти один запит;
* абстракція розроблена на майбутнє, яке не настало.</div>

</div>
Приклад:
}
В інформатиці, програмуванні, дизайні систем і мисленні абстракція користувачі можуть працювати зі складністю так, щоб людина або програма могла користуватися обєктом, функцією, системою чи ідеєю, не знаючи всіх внутрішніх механізмів.<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

* ORM приховує SQL, але повільний запит змушує читати EXPLAIN;
* cloud storage виглядає як файлова платформа, але має latency й eventual consistency;
* HTTP client приховує TCP, але timeout і retry все одно важливі;
* Docker приховує середовище, але permissions і volumes усе одно створюють проблеми;
* database transaction приховує concurrency, але deadlock усе одно здатна статися. * програмуванні;
* інформатиці;
* математиці;
* операційних системах;
* базах даних;
* мережах;
* API;
* обєктно-орієнтованому програмуванні;
* функціональному програмуванні;
* дизайні інтерфейсів;
* архітектурі програмного забезпечення;
* моделюванні предметної області;
* документації;
* навчанні;
* повсякденному мисленні. const stripe = new StripeClient(apiKey);

<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

'''Головна перевага:''' абстракція дає можливість людині працювати зі складною системою частинами, а не всією системою одразу.</div>

'''Цікавий факт:''' багато помилок у software design починаються не з коду, а з нечітких слів у моделі предметної області. як приклад, в інтернет-магазині виступає як поняття:
== Абстракція і повторне використання ==

</div>

Приклади:

Вона дає:

* бізнес-логіку;
* структуру даних;
* алгоритми;
* память;
* мережу;
* файлову систему;
* помилки;
* безпеку;
* протоколи;
* concurrency;
* hardware;
* user interface. Погана абстракція не зникає, вона без зусиль переїжджає в YAML.<div style="background:#e8f8f5; border-left:6px solid #16a085; padding:12px; margin:12px 0;">
</div>
Query planner

'''Практична роль:''' Docker абстрагує середовище застосунку, але не скасовує потребу розуміти мережу, volumes, security і ресурси. як приклад, базу даних можна пояснити на рівнях:

</div>

<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">
</div>
'''Generics''' дозволяють створювати абстракції над типами. constructor(private radius: number) {

 throw new Error("User not found");

Модульність тісно повязана з абстракцією. * Файл, бізнес-процес, база даних, HTTP-запит, клас, функція й API  усе це абстракції.== Encapsulation і Abstraction ==
</div>
=== Email service ===

function calculateTotal(price) {

'''Головне правило:''' хороша абстракція робить код простішим для використання й розуміння. оптимізує, коли:
'''Практична роль:''' generics дозволяють писати повторно використовуваний код без втрати типів.== Абстракція в документації ==

<syntaxhighlight lang="typescript">

<syntaxhighlight lang="javascript">

* ORM здатна генерувати неефективний SQL;
* framework здатна додавати overhead;
* wrapper здатна створювати зайві обєкти;
* virtual calls можуть бути повільнішими в частині мов;
* abstraction layer здатна ускладнити оптимізацію;
* generic solution здатна бути повільнішим за спеціалізований. '''Помилка:''' думати, що більше абстракцій автоматизовано означає кращу архітектуру. * дублювання коду;
* copy-paste логіка;
* зміна одного правила потребує редагування багатьох місць;
* функції занадто довгі;
* бізнес-логіка змішана з SQL, HTML, HTTP і файлами;
* складно тестувати;
* код важко читати;
* платформа сильно звязана. Замість того щоб у кожному місці писати логіку SMTP або API провайдера, створюють `EmailService`. Рекомендовано:
'''Leaky abstraction''' або дірява абстракція  це ситуація, коли приховані деталі все одно прориваються назовні. * SQL  приклад декларативної абстракції: користувач системи описує результат, а база вирішує спосіб виконання. платформа здатна мати багато рівнів абстракції. Спочатку потрібна корисна модель, а потім  деталі. Код вище не мусить кожного разу перевіряти всі деталі пошуку користувача. * over-abstraction;
* прихована складність;
* performance overhead;
* leaky abstractions;
* складний debugging;
* занадто загальні назви;
* неправильна модель предметної області;
* зайві шари;
* важко знайти реальну реалізацію;
* abstraction mismatch;
* фальшиве відчуття простоти;
* залежність від framework magic.

}

</syntaxhighlight>

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

Недоліки і ризики абстракції

Операційна платформа функціонує з диском

Приклад поганої і кращої абстракції

return user;

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

<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

== Приклад простої абстракції ==

<syntaxhighlight lang="typescript">

Кнопка `PrimaryButton` приховує CSS, hover state, accessibility attributes і дизайн-систему.<syntaxhighlight lang="python">
<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
Іноді абстракцію називають магією.<syntaxhighlight lang="typescript">

Бізнес-логіка функціонує з інтерфейсом `PaymentGateway`, а конкретна реалізація здатна бути Stripe, PayPal або інший сервіс. Кнопка зберегти  це абстракція над величезною кількістю технічних деталей. Але не всі абстракції повільні. // complex rendering
Модулі допомагають:
report.pdf

Інкапсуляція відповідає на питання: Що ми не дозволяємо змінювати напряму?

Приклад:

<syntaxhighlight lang="text">

* files замість raw disk blocks;
* processes замість ручного керування CPU;
* virtual memory замість фізичних адрес;
* sockets замість низькорівневої мережі;
* permissions замість прямого доступу до всього;
* drivers замість ручного керування пристроями;
* system calls як інтерфейс до ядра. Поширені помилки:
Мережеві протоколи побудовані шарами абстракції.</div>
== Абстракція в повсякденному житті ==

== Коли варто створювати абстракцію ==

* Матеріали з computer science щодо abstraction, data abstraction і control abstraction. Hardware зберігає біти
 async charge(amount: number): Promise<void> {
Приклад:

 .map(user => user.email);

як приклад, embedding  це абстрактне числове представлення тексту, зображення або іншого обєкта. '''Практична порада:''' абстракція має чітко показувати, як вона поводиться при помилках: повертає null, кидає exception або повертає Result. Але в критичних місцях потрібно вимірювати. '''Under-abstraction'''  протилежна проблема: коли абстракцій замало.</div>

== Хороші практики абстракції ==
send_email(user ["email"], subject, body)

Приклади:

id: UserId;

Він не описує вручну індекси, тимчасові масиви й лічильники. Який її public interface? Приклади алгоритмічних абстракцій:

Transport layer: TCP, UDP

* console logger;
* file logger;
* cloud logger;
* test logger. // complex data loading

* перевірку форми;
* обробку кошика;
* payment gateway;
* fraud checks;
* створення order;
* надсилання email;
* оновлення версій inventory;
* логування;
* webhook processing.</div>

== Control Abstraction ==

== Абстракція в програмуванні ==

як приклад:
<div style="background:#f0eaff; border-left:6px solid #8e44ad; padding:12px; margin:12px 0;">
<syntaxhighlight lang="text">

'''критично:''' ORM корисний, але не скасовує потребу розуміти SQL, індекси й транзакції.<syntaxhighlight lang="text">
 private async loadData(month: string) {
== Абстракція і generics ==
  • давати абстракціям точні назви;
  • приховувати нестабільні деталі;
  • не створювати шари без потреби;
  • проєктувати інтерфейс від користувача абстракції;
  • документувати обмеження;
  • робити абстракції тестованими;
  • уникати “магії” без пояснення;
  • не узагальнювати наперед;
  • видаляти непотрібні абстракції;
  • перевіряти performance у критичних місцях;
  • знати базові деталі рівня нижче;
  • розділяти domain logic і infrastructure;
  • не плутати abstraction з hiding everything.
  • візьми активних користувачів;
  • дістань їхні email. * Практики clean code, refactoring, domain modeling, API design і modular architecture. * disk sectors;
  • inode;
  • filesystem metadata;
  • permissions;
  • caching;
  • fragmentation;
  • physical storage;
  • SSD controller;
  • wear leveling. async send(email: string) {

Procedural Abstraction

Так само в коді рядок:

Чи можна буде змінити реалізацію без зміни користувачів? Приклад

users.append("Anna")

Розробник думає “пройдися по елементах”, а не “збільшуй індекс, перевіряй межі, діставай елемент”.== Абстракція і магія ==

ORM здатна приховувати:

У низькорівневому програмуванні абстракції теж існують, але вони тонші. Практична роль: API дає можливість різним системам домовитися про форму взаємодії, не розкриваючи всі внутрішні деталі. * Найгірші абстракції змушують розробника вивчити і саму абстракцію, і всі деталі під нею. * UI-кнопка здатна приховувати десятки технічних кроків. він не думає про:

Проста аналогія: операційна платформа — це перекладач між програмою й залізом. Практична роль: хороші абстракції дозволяють замінити зовнішні залежності в тестах. super();

  • користувач системи;
  • замовлення;
  • платіж;
  • повідомлення;
  • товар;
  • документ;
  • помилка;
  • бізнес-процес.</syntaxhighlight>
this.sent.push(email);

Тематичні мітки

Docker image приховує:

  • створювати interface для кожного класу без потреби;
  • називати все Manager або Helper;
  • ховати просту логіку за багатьма шарами;
  • не створювати функції й копіювати код;
  • думати, що абстракція завжди означає ООП;
  • не розуміти деталей нижчого рівня;
  • сліпо довіряти ORM;
  • не читати SQL, який генерує abstraction layer;
  • робити generic solution без реальних сценаріїв;
  • не документувати edge cases;
  • приховувати помилки;
  • робити API, яке виглядає простим, але має небезпечні side effects. {| class="wikitable"
}

for (const item of items) { користувач системи натискає кнопку

console.log(total);

Код, який приймає `PaymentProvider`, не мусить знати, чи це Stripe, PayPal або інший provider. Найлюдяніший факт: абстракція — це причина, чому програміст здатна думати про “користувача”, “замовлення” або “повідомлення”, а не про кожен байт у пам’яті. Він викликає `calculateTotal`. * Класичні підручники з software engineering. Це дає можливість тестувати бізнес-логіку без реального надсилання листів. Головне правило: абстракція має зменшувати когнітивне навантаження, а не створювати нову загадку.

У функціональному програмуванні абстракція часто будується навколо функцій, композиції й трансформацій даних. Чи не приховує вона важливі обмеження?</syntaxhighlight>

}

  • extract function;
  • extract class;
  • introduce interface;
  • replace conditional with strategy;
  • move logic to domain service;
  • remove unnecessary abstraction;
  • inline function;
  • split module;
  • create facade;
  • simplify API. Приклади:
  • документувати структуру;
  • ловити помилки;
  • описувати контракти;
  • робити refactoring;
  • покращувати autocomplete;
  • передавати доменні поняття.

У математиці абстракція дає можливість працювати з загальними структурами замість конкретних об’єктів.</syntaxhighlight> </syntaxhighlight> }

Абстракція оптимізує зменшити coupling між частинами системи.

</syntaxhighlight>

  • feature vectors;
  • embeddings;
  • model architecture;
  • labels;
  • prompts;
  • tokens;
  • latent representations;
  • agents;
  • tools;
  • policies;
  • evaluation metrics. * Customer;
  • Product;
  • Order;
  • Payment;
  • Shipment;
  • Discount;
  • Cart;
  • Invoice.
    WAL і recovery
    
    '''Procedural abstraction'''  це винесення послідовності дій у процедуру або функцію. Багато з них компілюються або оптимізуються дуже добре. Тип `User` дає можливість говорити про користувача як про окреме поняття, а не без зусиль про набір полів.
    
Docker — приклад абстракції середовища запуску. Вона дає можливість створювати моделі.
критично: Kubernetes додає потужні абстракції, але так само додає складність. Коли людина натискає кнопку “зберегти”, вона не думає про файлову систему, кеш, драйвер диска, блоки пам’яті й електричні сигнали.

Основні конкурентні переваги абстракції:

await emailService.sendWelcomeEmail(user);

  • розділяти код;
  • зменшувати залежності;
  • покращувати тестування;
  • контролювати public API;
  • приховувати internal functions;
  • полегшувати refactoring;
  • розвивати систему частинами. Без абстракції розробник мав би одночасно тримати в голові:
const tax = price * 0.2;

Приклади:

! Краще для тестованості й заміни provider:

</div>
Service layer виконує бізнес-логіку

<syntaxhighlight lang="typescript">

<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

Учню не потрібно знати все одразу. Застосунок викликає `storage.save(file)`, а реалізація здатна використовувати S3, Google Cloud Storage або локальну файлову систему. Слабка або надмірна абстракція, навпаки, додає магію, приховує важливі обмеження й ускладнює debugging. '''критично:''' interface має описувати стабільну поведінку, а не випадкові деталі поточної реалізації.<syntaxhighlight lang="sql">

 .filter(user => user.active)
<syntaxhighlight lang="text">
'''Проста різниця:''' abstraction  це про спрощення моделі, encapsulation  про контроль доступу до деталей. }
Абстракція здатна бути зайвою, якщо:
 abstract area(): number;

 if (!user) {

* SQL;
* joins;
* mapping rows to objects;
* migrations;
* query building;
* relations;
* transactions у частині сценаріїв.<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

 await this.saveFile(pdf);
 error(message: string): void;
async function getUserOrThrow(id: string) {
В архітектурі програмного забезпечення абстракція оптимізує розділяти відповідальності. Чи зрозуміє її інший розробник через місяць? Суть

Типи  форма абстракції. * Хороша абстракція не приховує правду, вона приховує шум. З абстракцією:
Абстракція дає можливість розділити систему на зрозумілі частини. '''Data abstraction''' або '''абстракція даних'''  це приховування деталей зберігання й представлення даних за зрозумілим інтерфейсом.</div>

виглядає без зусиль, але за ним стоять runtime, стандартні потоки виводу, операційна платформа, terminal, buffers і багато низькорівневих механізмів. Практична роль: цей checklist оптимізує відрізнити корисну абстракцію від зайвого архітектурного шару. * залежності;

  • версію runtime;
  • системні бібліотеки;
  • файлову структуру;
  • startup command;
  • частину конфігурації. Application layer: HTTP, DNS, SMTP

Data Abstraction

У другому прикладі зрозуміліше:

Типи допомагають:

  • приховує секрети;
  • централізує перевірку прав;
  • уніфікує validation;
  • дає безпечний API;
  • прибирає прямий доступ до небезпечних операцій;
  • стандартизує logging і audit. Вона дає можливість приховувати складні деталі, виділяти суттєве, створювати зрозумілі інтерфейси й будувати великі системи з менших частин.== Абстракція і мова ==
В об’єктно-орієнтованому програмуванні абстракція означає моделювання сутностей через класи, об’єкти, інтерфейси й методи. Практична порада: хороша абстракція здатна бути зручною, але не повинна бути непрозорою магією. критично: документація має рухатися від простого до складного, як сходи абстракції.

console.log(calculateTotal(100)); Поганий підхід:

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

Файл — це абстракція.== Абстракція і штучний інтелект ==

Коли абстракцію краще не створювати

</syntaxhighlight>

  • Абстракція виступає як однією з головних причин, чому сучасне програмування взагалі можливе. * незрозуміло, який код виконується;
  • важко debug;
  • поведінка залежить від naming convention;
  • implicit dependencies;
  • приховані side effects;
  • складно знайти джерело помилки;
  • документація слабка;
  • framework “сам усе робить”, поки не ламається. * Матеріали щодо object-oriented programming, encapsulation, design patterns і software architecture. Тепер користувач системи функції не думає про формулу щоразу. * код повторюється;
  • виступає як кілька схожих реалізацій;
  • деталі реалізації часто змінюються;
  • потрібно спростити public API;
  • потрібно ізолювати зовнішній сервіс;
  • потрібно полегшити тестування;
  • виступає як чітке доменне поняття;
  • логіка стала занадто довгою;
  • частина системи має окрему відповідальність;
  • потрібно стабілізувати контракт між модулями.
calculateTotal(invoice: Invoice): Money {
}

Чи має абстракція зрозумілу назву? email: string; Абстракція існує не лише в коді. * virtual machine приховує фізичний сервер;

  • object storage приховує диски й replication;
  • managed database приховує частину адміністрування;
  • serverless function приховує сервер;
  • container platform приховує вузли;
  • load balancer приховує набір backend-серверів. await stripe.charge(amount);

Over-abstraction

Абстракція і алгоритми

як приклад, `for` приховує ручне керування лічильником:

Facade як приклад абстракції

критично: низькорівневе програмування не означає “без абстракцій”. Функція `first` функціонує з різними типами, але зберігає типову інформацію. const tax = price * 0.2; Цікавий факт: `map`, `filter` і `reduce` — це дуже сильні абстракції, бо дозволяють описувати трансформації даних без ручного керування циклом. }

Практична роль: архітектурна абстракція дає можливість змінювати частини системи, не переписуючи все одразу.</syntaxhighlight>

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

Абстракція здатна приховувати не тільки успішну роботу, а й спосіб обробки помилок. * Документація мов програмування щодо functions, classes, interfaces, modules і generics. Він має працювати з поняттями предметної області. Ознаки over-abstraction: </syntaxhighlight>

<syntaxhighlight lang="python">

Практична роль: хороше навчання — це правильно підібраний рівень абстракції для поточного етапу.

<syntaxhighlight lang="typescript">

Рефакторинг часто створює або змінює абстракції.
  • сторінки на диску;
  • B-tree індекси;
  • кеш;
  • locks;
  • transaction logs;
  • query planner;
  • storage engine;
  • physical blocks;
  • WAL;
  • buffer pool. Підказка: хороша абстракція часто має дієслівну або доменну назву: `sendEmail`, `createOrder`, `calculateTax`, `UserRepository`, `PaymentGateway`. Storage engine

interface PaymentGateway { Чи не створюємо ми її занадто рано? * Computer Science

Поширені шари: