Эта замечательная статья подтолкнула меня опубликовать давние мысли, касающиеся моделирования предметной области с помощью объектно-ориентированного программирования.
К актуальности изложенных в статье идей, приходишь подспудно (не имея возможности выразить по причине того, что парадигме моделирования в терминах теории множеств не учат в вузах, будущих «программистов», по крайней мере), долго работая с ООП и реляционными базами данных:
Каждый раз при моделировании предметной области, оперируя терминами ООП (сейчас говорим не об этапе бизнес-анализа, а о последующем этапе реализации модели в коде), для всех сущностей предметной области приходится реализовывать в коде и схеме БД следующий паттерн, состоящий их «подсущностей», связанных между собой:
- класс/таблицу вида «Машины» (здесь и далее класс употребляю в терминах ООП);
- класс/таблицу вида «Список машин»;
- класс/таблицу вида «Машина».
Далее с помощью механизмов ООП и реляционной модели «подсущности связываются между собой.
Причем термины „сущность“ и „подсущность“ применимы именно к модели предметной области в терминах теории множеств,
а в терминах ООП/реляционной модели уместны термины „метасущность“ и „сущность“ соответственно.
Надеюсь, понятно, почему? — ООП/реляционная модель являются более низкоуровневыми механизмами, и сущность предметной области приходится конструировать, нет в них средств, которые нативными образом позволили бы отразить сущность предметной области.
А далее следуют ожидаемые проблемы:
Каждый раз (не только в каждом проекте, а внутри проекта для каждой сущности, подчеркну это) реализуем паттерн?
Отлично, мы занимаемся копипастом.
[offtopic]Отвлекаясь, хотелось бы сказать, я достаточно критически отношусь к паттернам (тема такая модная лет 10-15 уже как; чего ведь только не придумывают вместо того, чтобы заниматься моделированием и написанием качественного кода),
т.к. паттертн — это копипаст по своей сути (если кому-то захочется поспорить на тему — пожалуйста не здесь, заведите публикацию, там поговорим).[/offtopic]
Либо, если хочется сократить себе работу/не заниматься копипастом (или в случае отсутствия понимания необходимости реализации описанного паттерна), в большинстве случаев делается так, реализуется лишь одна сущность:
- Код:
- класс „Машина“ — не множество, а именно характеристики машины, ее описание;
- список машин представляется абы как — массив (Array), список (List), или перечисление (IEnumerable), т.е. используются низкоуровневые типы данных языка для реализации сущности „список“ — но с такими данными мы можем делать, все что хотим или что случайно получится, а это уже не объектный, а процедурный подход со всеми вытекающими;
- класс же „машины“ чаще всего вообще не реализуется ни в каком виде.
- БД:
- Как правило, это одна таблица „Машина“ или „Машины“ — таблица, строки которых содержат список машин, а столбцы — характеристики машин.
- Никогда не задумывались, почему в книжках по БД такую таблицу называют, то „Машина“, то „Машины“ (Student/Students)?
Есть фреймворки по работе с БД, которые принудительно к названиям таблиц добавляют суффикс „s“ (Mashines/Students). - Причина в том, что здесь происходит попытка объединить две сущности в одну (объект и список объектов), или даже все три в одну.
- Правильно называть такую таблицу „Машина“, а „Список машины“ и „Машины“ реализовывать с помощью других таблиц.
Так вот, какой же вывод я делаю на основании своего опыта и комментируемой статьи:
Хотелось бы иметь такие язык программирования, платформу разработки, теорию БД, СУБД, которые позволили бы в „нативных“ для себя терминах реализовывать модель предметной области в терминах именно теории множеств.
Мне кажется, необходимость появления таких инструментов в мейнстриме давно уже назрела.
Recommended article: Chomsky: We Are All – Fill in the Blank.
This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.
Комментариев нет:
Отправить комментарий