Здравствуйте.

Коллеги, некоторое время назад меня заинтересовали исследования maxstroy на тему анализа и моделирования предметной области в логической парадигме с применением объекто-ориентированных средств.


Автор говорит большей частью об этапе анализа и моделирования. Меня заинтересовало, каким именно образом можно реализовать предложенные идеи в программном коде и схеме базы данных.

Когда мы получаем по итогам исследования и анализа предметной области ее модель, ее необходимо реализовать в программном коде.


До настоящего момента в Enterprise-разработке преобладали объектно-ориентированные языки программирования, и занимают значительную долю и на текущий момент, уступив немного мультипарадигменным языкам (Ruby, Golang, JavaScript, современные версии C#, Java).

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


Ранее я дал предварительные комментарии, и на данный момент оформил их виде развернутой статьи, которую предлагаю вашему вниманию.
Также можно посмотреть итоговые результаты исследований maxstroy в виде статьи.

Комментарии (6)


  1. RPG18
    28.10.2015 01:23

    Мне кажется ошибочным утверждением, что раз что-то в ОО языке нет, то это «неполнота» ООП.
    Тимоти Бадд в своей книге рекомендует начинать с функционирования. Если мне нужна сущность, что бы работать с множествами, то я создам соответствующую сущность. На вашем такая сущность бы называлось стадо слонов.


  1. lair
    28.10.2015 01:52
    +4

    Эмм, а это нынче так модно — размещать статью на другом ресурсе, чтобы здесь ее было неуместно комментировать?


  1. MichaelBorisov
    28.10.2015 02:19

    Мне показалось, или автор статьи «изобрел» контейнеры — интрузивные и неинтрузивные?

    Разве шаблоны C++ не позволяют реализовать все эти концепции, да еще и абстрагированно от структуры данных, реализующей контейнер?


    1. sand14
      28.10.2015 07:17

      В статье речь об очевидных вещах.
      Однако, в реальных проектах для решения задач, о которых рассказывается в статье, часто можно наблюдать не контейнер, а public static-поле.

      Статья в большей степени предназначена для аналитиков, чем для разработчиков:
      1. Разработчики, которые понимают, о чем речь в статье, сами напишут контейнер или используют готовый фреймворк. И вот тут как раз и хотелось бы указать на «неполноту» ООП, которое требует применения контейнеров для решения простой задачи.
      2. Разработчики, которые являются убежденными сторонниками static-полей, так и продолжат их использовать.
      3. А вот аналитикам будет полезно узнать, во что превращаются их модели на этапе разработки в случае, если этап проектирования (между этапами анализа и разработки) был пропущен.


      1. lair
        28.10.2015 11:27

        Однако, в реальных проектах для решения задач, о которых рассказывается в статье, часто можно наблюдать не контейнер, а public static-поле.

        Можете привести пример из реального проекта и реальной задачи?

        А вот аналитикам будет полезно узнать, во что превращаются их модели на этапе разработки в случае, если этап проектирования (между этапами анализа и разработки) был пропущен.

        А зачем им это? Они начнут подгонять свои модели под разработку, а это заведомо ошибочный шаг.


  1. wheercool
    28.10.2015 02:36
    +1

    Извините, но по мне это сплошная схоластика :)
    И еще как мне показалось, кому-то просто надо срочно публикацию сделать )