Pull to refresh

На тему моделирования предметной области в терминах ООП

Reading time 3 min
Views 15K

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


К актуальности изложенных в статье идей, приходишь подспудно (не имея возможности выразить по причине того, что парадигме моделирования в терминах теории множеств не учат в вузах, будущих «программистов», по крайней мере), долго работая с ООП и реляционными базами данных:

Каждый раз при моделировании предметной области, оперируя терминами ООП (сейчас говорим не об этапе бизнес-анализа, а о последующем этапе реализации модели в коде), для всех сущностей предметной области приходится реализовывать в коде и схеме БД следующий паттерн, состоящий их «подсущностей», связанных между собой:
  • класс/таблицу вида «Машины» (здесь и далее класс употребляю в терминах ООП);
  • класс/таблицу вида «Список машин»;
  • класс/таблицу вида «Машина».

Далее с помощью механизмов ООП и реляционной модели «подсущности» связываются между собой.

Причем термины «сущность» и «подсущность» применимы именно к модели предметной области в терминах теории множеств,
а в терминах ООП/реляционной модели уместны термины «метасущность» и «сущность» соответственно.
Надеюсь, понятно, почему? — ООП/реляционная модель являются более низкоуровневыми механизмами, и сущность предметной области приходится конструировать, нет в них средств, которые нативными образом позволили бы отразить сущность предметной области.

А далее следуют ожидаемые проблемы:


Каждый раз (не только в каждом проекте, а внутри проекта для каждой сущности, подчеркну это) реализуем паттерн?
Отлично, мы занимаемся копипастом.

[offtopic]Отвлекаясь, хотелось бы сказать, я достаточно критически отношусь к паттернам (тема такая модная лет 10-15 уже как; чего ведь только не придумывают вместо того, чтобы заниматься моделированием и написанием качественного кода),
т.к. паттерн — это копипаст по своей сути (если кому-то захочется поспорить на тему — пожалуйста не здесь, заведите публикацию, там поговорим).[/offtopic]

Либо, если хочется сократить себе работу/не заниматься копипастом (или в случае отсутствия понимания необходимости реализации описанного паттерна), в большинстве случаев делается так, реализуется лишь одна сущность:


  1. Код:
    • класс «Машина» — не множество, а именно характеристики машины, ее описание;
    • список машин представляется абы как — массив (Array), список (List), или перечисление (IEnumerable), т.е. используются низкоуровневые типы данных языка для реализации сущности «список» — но с такими данными мы можем делать, все что хотим или что случайно получится, а это уже не объектный, а процедурный подход со всеми вытекающими;
    • класс же «Машины» чаще всего вообще не реализуется ни в каком виде.
  2. БД:
    • Как правило, это одна таблица «Машина» или «Машины» — таблица, строки которых содержат список машин, а столбцы — характеристики машин.
    • Задумывались, почему в книжках по БД такую таблицу называют, то «Машина», то «Машины» (Student/Students)? А есть фреймворки по работе с БД, которые принудительно к названиям таблиц добавляют суффикс "s" (Mashines/Students).
      Причина в том, что здесь происходит попытка объединить две сущности в одну (объект и список объектов), или даже все три в одну.
    • Правильно называть такую таблицу «Машина», а «Список машин» и «Машины» реализовывать с помощью других таблиц.

Так вот, какой же вывод я делаю на основании своего опыта и комментируемой статьи:


Хотелось бы иметь такие язык программирования, платформу разработки, теорию БД, СУБД, которые позволили бы в «нативных» для себя терминах реализовывать модель предметной области в терминах именно теории множеств.
Мне кажется, необходимость появления таких инструментов в мейнстриме давно уже назрела.
Tags:
Hubs:
+3
Comments 44
Comments Comments 44

Articles