Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-26

1 Абстракции позволяют нам моделировать необходимую предметную область.Попробуем понять это утверждение на конкретном примере. Допустим, мы хотим сделать программу-каталог для управления коллекцией книг. Вы можете сразу кинуться писать код, но так делать не стоит :)

2 В первую очередь необходимо проанализировать предметную область (книги + каталоги) и сформировать базовую модель. Нужно начать с определения сущностей и операций над ними. В случае нашего каталога у нас есть по крайней мере две сущности: книга и коллекция. Базовыми операциями сделаем добавление книги в коллекцию и удаление её из коллекции.

3 Напишем код операции для добавления сущности в коллекцию:

4 Мы создаём две книги, одну коллекцию и добавляем эти книги в коллекцию. Что значит "создали книгу"? Что такое "книга"? Книга - это сущность, которая ведёт себя как книга. Что это значит?

5 Так как мы работаем с языком программирования, то конструктор makeBook, создающий книгу, возвращает какие-то данные: примитивные (число, строку) или составные, используя пары. Главное - намне важно, как они устроены.

6 Организовать эти данные можно тысячью разных способов, и конкретный способ зависит от разработчика, его предпочтений и данных, которые необходимо хранить. То, что книга является книгой, определяется не её внутренним устройством, а тем, что к ней применим набор операций, созданный для книг. Например, операция "получить имя книги". Сами операции знают, как устроены данные, иначе они не смогли бы ими манипулировать. Запомните: это детали реализации. Не заглянув внутрь операций, мы не узнаем, как они устроены, но нам это и не нужно.

7 В этом и заключается вся суть абстракции. Мы знаем, как создать сущность и какие операции к ней применимы. Обычно это и называется дизайном кода, а сами операции + конструктор - это API или интерфейс модуля/пакета/библиотеки.

8 Получаем следующий алгоритм:

9 <ol><li>Анализируем предметную область. Выделяем сущности.</li>

10 <li>Реализуем конструктор. Внутреннее представление сущностей выбираем на основе того, что мы планируем в них хранить.</li>

11 <li>Реализуем необходимые операции.</li>

12 </ol>В примере с книгами видно, что мы храним только название. А это значит, что нам достаточно хранить одну строчку.

13 Тогда реализация конструктора будет такой:

14 А что, если мы захотим дополнительно хранить версию издания книги? Тогда мы можем использовать пары для хранения составных данных, и у нас уже появляютсясоставные данные, так как нужно хранить два параметра.

15 Поменяется ли клиентский код, использующий нашу библиотеку, при изменении внутренней структуры? Как видно из примеров выше, ничего не поменяется, кроме вызова конструкторов. Это и есть хорошая абстракция, при которой наш код не рассыпается в случае любых изменений внутренней реализации.

16 <h2>Примеры других абстракций</h2>

17 Пример с книгами - это всего лишь один из многих вариантов. Программисты в своей работе постоянно перекладывают сущности реального мира на код, создавая всевозможные абстракции данных. Давайте попробуем пофантазировать и накидать ещё вариантов. Я добавлю только три, а ещё три додумайте сами. В реальной жизни абстракции будут сложнее, так как должны включать больше данных, но суть от этого не поменяется.

18 <ol><li>Товар. Всё, что продаётся и покупается. Предположим, что нам интересны только два параметра: цена и название. Саму сущность можно назвать product. Тогда наша абстракция будет содержать как минимум три следующих функции:

19 </li>

20 <li>Текстовый документ. Например, как в Google Docs. В нашем примере он будет состоять из названия и содержимого.

21 </li>

22 <li>А вот пример, в котором нужно хранить не два значения, а три. Этоточка в пространстве.

23 </li>

24 </ol>И теперь самое интересное.Любая абстракция, построенная таким образом, может выступать в роли строительных блоков в другой абстракции.

25 Предположим, что мы продаём документы как продукты:

26 А дальше всё по аналогии.