Коллеги, некоторое время назад меня заинтересовали исследования maxstroy на тему анализа и моделирования предметной области в логической парадигме с применением объекто-ориентированных средств.
Автор говорит большей частью об этапе анализа и моделирования. Меня заинтересовало, каким именно образом можно реализовать предложенные идеи в программном коде и схеме базы данных.
Когда мы получаем по итогам исследования и анализа предметной области ее модель, ее необходимо реализовать в программном коде.
До настоящего момента в Enterprise-разработке преобладали объектно-ориентированные языки программирования, и занимают значительную долю и на текущий момент, уступив немного мультипарадигменным языкам (Ruby, Golang, JavaScript, современные версии C#, Java).
Предлагаю рассмотреть, как в объектно-ориентированной парадигме запрограммировать сущности предметной области, учитывая, что ООП нам предоставляет средства описания типов данных и порождения их экземпляров, а нам необходимы еще и средства описания и управления множествами экземпляров, в т.ч. в учетных системах.
Ранее я дал предварительные комментарии, и на данный момент оформил их виде развернутой статьи, которую предлагаю вашему вниманию.
Также можно посмотреть итоговые результаты исследований maxstroy в виде статьи.
Комментарии (6)
lair
28.10.2015 01:52+4Эмм, а это нынче так модно — размещать статью на другом ресурсе, чтобы здесь ее было неуместно комментировать?
MichaelBorisov
28.10.2015 02:19Мне показалось, или автор статьи «изобрел» контейнеры — интрузивные и неинтрузивные?
Разве шаблоны C++ не позволяют реализовать все эти концепции, да еще и абстрагированно от структуры данных, реализующей контейнер?
sand14
28.10.2015 07:17В статье речь об очевидных вещах.
Однако, в реальных проектах для решения задач, о которых рассказывается в статье, часто можно наблюдать не контейнер, а public static-поле.
Статья в большей степени предназначена для аналитиков, чем для разработчиков:
1. Разработчики, которые понимают, о чем речь в статье, сами напишут контейнер или используют готовый фреймворк. И вот тут как раз и хотелось бы указать на «неполноту» ООП, которое требует применения контейнеров для решения простой задачи.
2. Разработчики, которые являются убежденными сторонниками static-полей, так и продолжат их использовать.
3. А вот аналитикам будет полезно узнать, во что превращаются их модели на этапе разработки в случае, если этап проектирования (между этапами анализа и разработки) был пропущен.lair
28.10.2015 11:27Однако, в реальных проектах для решения задач, о которых рассказывается в статье, часто можно наблюдать не контейнер, а public static-поле.
Можете привести пример из реального проекта и реальной задачи?
А вот аналитикам будет полезно узнать, во что превращаются их модели на этапе разработки в случае, если этап проектирования (между этапами анализа и разработки) был пропущен.
А зачем им это? Они начнут подгонять свои модели под разработку, а это заведомо ошибочный шаг.
wheercool
28.10.2015 02:36+1Извините, но по мне это сплошная схоластика :)
И еще как мне показалось, кому-то просто надо срочно публикацию сделать )
RPG18
Мне кажется ошибочным утверждением, что раз что-то в ОО языке нет, то это «неполнота» ООП.
Тимоти Бадд в своей книге рекомендует начинать с функционирования. Если мне нужна сущность, что бы работать с множествами, то я создам соответствующую сущность. На вашем такая сущность бы называлось стадо слонов.