PHP: Абстракция с помощью данных
2026-02-26 20:51 Diff
https://ru.hexlet.io/courses/php-data-abstraction/lessons/ontology/theory_unit

Программы, которые пишут программисты, всегда создаются под определённую предметную область. Например, бухгалтерский софт основывается на правилах ведения бухгалтерского учёта, а сайт для просмотра сериалов — на понятиях из телеиндустрии, таких, как "сезон" или "эпизод". То же самое относится и ко всему остальному: бронирование авиабилетов, отелей, поиск туров, продажа и покупка автомобилей и так далее.

Понимание предметной области, для которой вы пишете программу, так же важно, как и умение программировать. Это не значит, что её нужно знать досконально — иногда область может быть по-настоящему сложной (например, та же бухгалтерия или технологическое производство), но общее понимание всё же требуется.

Рассмотрим в качестве примера Хекслет, так как вы с ним достаточно хорошо знакомы. Вы неплохо знаете его предметную область, хотя вряд ли думали о ней так, как мы сделаем это сейчас. В первую очередь, для её понимания нужно выделить ключевые понятия. У обучающих ресурсов это, как правило, "курс" и "урок", но на самом деле их гораздо больше. В случае Хекслета ещё можно выделить профессию, испытание (практика после курса), ревью кода, квиз (набор вопросов и ответов), участника курса (вы становитесь участником, когда вступаете в курс), проект. Этот список можно продолжать ещё долго. Вероятно, вы удивитесь, но на Хекслете более 200 подобных понятий, которые также называют сущностями, и все они описаны в коде.

Сущности находятся в некоторых взаимоотношениях друг с другом. Например, квиз содержит (агрегирует) в себе вопросы. А каждый вопрос, в свою очередь, содержит в себе ответы. Профессия состоит из курсов, а курсы — из уроков, уроки — из теории, квиза и практики. Эти связи имеют конкретные названия. Например:

  • Один урок может находиться только в одном курсе, но курс содержит множество уроков. Такая связь называется "один ко многим" (one-to-many или o2m).
  • Один курс могут проходить множество пользователей, и один пользователь может проходить много курсов. Такая связь уже называется "многие ко многим" (many-to-many или m2m).
  • Реже встречается отношение "один к одному" (one-to-one или o2o). На Хекслете так связаны пользователь и эксперт.

В реальности всё ещё чуть сложнее, потому что одна и та же сущность с точки зрения разных систем может выглядеть совершенно по-разному. Пользователь Хекслета с точки зрения бухгалтера (а у нас есть бухгалтер!) и с точки зрения наставника — две большие разницы.

Описание объектов рассматриваемой области и связей между ними называется онтологией предметной области. Эту онтологию хорошо знают эксперты соответствующей области (в бухгалтерии — бухгалтер, в обучении — преподаватель). Но, в отличие от программистов, они часто представляют её на интуитивном уровне, неформально. На практике программисты (или бизнес-аналитики и менеджеры) общаются с заказчиками, которые могут сами выступать в роли экспертов и строят вместе с ними формальную онтологию (этот процесс происходит постоянно в процессе развития проекта и не выделяется в отдельный этап проектирования). То есть выделяют конкретные термины, договариваются о том, что они означают и как связаны друг с другом. Затем с помощью ER-модели программист формирует необходимую модель данных. ER-модель это конкретный способ описания объектов и связей между ними. ER-модель используется при высокоуровневом (концептуальном) проектировании баз данных. На этом этапе уже проявляются зачатки архитектуры будущего приложения.

Далеко не всегда можно однозначно сказать, какая связь существует между двумя сущностями. Иногда программисты думают наперёд и сразу формируют более сложные связи, например, m2m, а не o2m, что сказывается на сложности кода. Чем сложнее связь, тем больше кода и выше стоимость его создания и поддержки. Сложность связей можно описать так (правее — сложнее): o2o, o2m, m2m. Иногда программисты ошибаются при выборе той или иной связи, что обычно говорит о недостаточно хорошем понимании предметной области. Приведу интересный пример. Предположим, что в системе нужно реализовать пользователя и заграничный паспорт. Интуитивно кажется, что между этими понятиями связь один к одному: ведь один пользователь может иметь один заграничный паспорт. Так? Не совсем: паспорт может поменяться, если он был утерян или закончился его срок действия. К тому же, в некоторых странах разрешено владение одновременно несколькими заграничными паспортами.

С другой стороны, реальный мир всегда сложнее и полнее, чем любая модель. И задача программиста состоит не в том, чтобы создать универсальную и всеобъемлющую модель некоторой области, а в том, чтобы понять потребности конкретного бизнеса, выделить для них только значимые части рассматриваемой предметной области и перенести их в код.

В зависимости от языка меняется способ представления сущностей в коде. В некоторых определяются типы (используя абстрактные типы данных, интерфейсы или классы), в других — структуры, а третьи вообще не предоставляют никаких вариантов, кроме словарей (ассоциативных массивов).

Со следующего урока мы начнём изучать различные предметные области и строить подходящие модели данных, попутно изучая новые возможности PHP.

Наиболее полно рассматриваемая тема раскроется тогда, когда мы начнём изучать ORM. Это специализированные фреймворки, которые определяют способ создания сущностей и их связывания. Они используются для упрощения описания предметной области и хранения её данных в приложениях. Сейчас достаточно того, что у вас есть общее представление о предметной области, сущностях и связях. Не забудьте почитать информацию по приведённым ссылкам — чем больше вопросов появится на этом этапе, тем лучше.