На тему моделирования предметной области в терминах ООП
Здравствуйте.Эта замечательная статья подтолкнула меня опубликовать давние мысли, касающиеся моделирования предметной области с помощью объектно-ориентированного программирования.К актуальности изложенных в статье идей, приходишь подспудно (не имея возможности выразить по причине того, что парадигме моделирования в терминах теории множеств не учат в вузах, будущих «программистов», по крайней мере), долго работая с ООП и реляционными базами данных: Каждый раз при моделировании предметной области, оперируя терминами ООП (сейчас говорим не об этапе бизнес-анализа, а о последующем этапе реализации модели в коде), для всех сущностей предметной области приходится реализовывать в коде и схеме БД следующий паттерн, состоящий их «подсущностей», связанных между собой:
класс/таблицу вида «Машины» (здесь и далее класс употребляю в терминах ООП); класс/таблицу вида «Список машин»; класс/таблицу вида «Машина». Далее с помощью механизмов ООП и реляционной модели «подсущности связываются между собой.Причем термины «сущность» и «подсущность» применимы именно к модели предметной области в терминах теории множеств, а в терминах ООП/реляционной модели уместны термины «метасущность» и «сущность» соответственно.Надеюсь, понятно, почему? — ООП/реляционная модель являются более низкоуровневыми механизмами, и сущность предметной области приходится конструировать, нет в них средств, которые нативными образом позволили бы отразить сущность предметной области.
А далее следуют ожидаемые проблемы: Каждый раз (не только в каждом проекте, а внутри проекта для каждой сущности, подчеркну это) реализуем паттерн? Отлично, мы занимаемся копипастом.[offtopic]Отвлекаясь, хотелось бы сказать, я достаточно критически отношусь к паттернам (тема такая модная лет 10–15 уже как; чего ведь только не придумывают вместо того, чтобы заниматься моделированием и написанием качественного кода), т.к. паттертн — это копипаст по своей сути (если кому-то захочется поспорить на тему — пожалуйста не здесь, заведите публикацию, там поговорим).[/offtopic]
Либо, если хочется сократить себе работу/не заниматься копипастом (или в случае отсутствия понимания необходимости реализации описанного паттерна), в большинстве случаев делается так, реализуется лишь одна сущность: Код: класс «Машина» — не множество, а именно характеристики машины, ее описание; список машин представляется абы как — массив (Array), список (List), или перечисление (IEnumerable), т.е. используются низкоуровневые типы данных языка для реализации сущности «список» —, но с такими данными мы можем делать, все что хотим или что случайно получится, а это уже не объектный, а процедурный подход со всеми вытекающими; класс же «машины» чаще всего вообще не реализуется ни в каком виде. БД: Как правило, это одна таблица «Машина» или «Машины» — таблица, строки которых содержат список машин, а столбцы — характеристики машин. Никогда не задумывались, почему в книжках по БД такую таблицу называют, то «Машина», то «Машины» (Student/Students)? Есть фреймворки по работе с БД, которые принудительно к названиям таблиц добавляют суффикс «s» (Mashines/Students). Причина в том, что здесь происходит попытка объединить две сущности в одну (объект и список объектов), или даже все три в одну. Правильно называть такую таблицу «Машина», а «Список машины» и «Машины» реализовывать с помощью других таблиц. Так вот, какой же вывод я делаю на основании своего опыта и комментируемой статьи: Хотелось бы иметь такие язык программирования, платформу разработки, теорию БД, СУБД, которые позволили бы в «нативных» для себя терминах реализовывать модель предметной области в терминах именно теории множеств.Мне кажется, необходимость появления таких инструментов в мейнстриме давно уже назрела.
