Business Objects: Re-Engineering for Re-Use, или кому не хватает ООП

По наводке [info]ailev ознакомился с книжкой Криса Партриджа «Business Objects: Re-Engineering for Re-Use». Прекрасное чтение после какого-нибудь руководства по «мейнстримному» объектно-ориентированному проектированию с использованием UML, а главное — в любимом мной жанре «прикладной философии».

Как и полагается в книгах такого типа, где предлагается какой-то фундаментально новый подход, не обошлось без вступления в духе «вы все пидоры, а я Д’Артаньян». Утверждается, что «стандартный» подход к проектированию информационных систем, который автор назвал «сущностным» (entity), несмотря на все заявления его авторов, не позволяет строить сколь-либо сложные модели реальных систем, и не позволяет прямо соотнести возникающие сущности с реальностью. Это подтверждается примером из статьи Стива Кука и Джона Дениэлса «Object-Oriented Methods and the Great Object Myth», в котором «миф» о том, что мир состоит из объектов и операций (взаимно-однозначно соответствующих объектам и операциям в модели) разрушается простым примером — когда мы пьем чай, мы не вызываем операцию «пить», принадлежащую объекту «чашка» — и вообще, представить это простое действие с помощью «объектно-ориентированной» модели очень сложно.

Для нового, единственно верного и всячески правильного подхода к проектированию предлагается сменить парадигму — то есть смотреть на мир, не как на состоящий из сущностей (entity, это общепринятый термин, например, в так называемой ER-модели) или субстанций (substance, это более высокий уровень абстракции и общепринятый философский термин), а составленный из более сложных для представления «объектов». То, что называется «объектами» в учебниках по ООП — это, в терминологии книги, «сущности» либо «субстанции». Картина мира, использующая «сущности», неявно существует и в «бумажных» информационных системах. Взаимно-однозначное соответствие между терминами из теории реляционных БД, «бумажных» картотек и «сущностной» парадигмы — не просто совпадение, а подтверждение единой картины мира, представляемой тремя способами.

В любой предметной области можно выделить четыре «рода» вещей (kinds of things) — конкретные вещи («белый ВАЗ-2101 с проколотыми колесами, ржавеющий в моем дворе»), типы вещей («все автомобили «Жигули»»), отношения между вещами («Иван Иваныч — владелец белого ВАЗ-2101 и далее по тексту») и изменения, происходящие с этими вещами (вышеупомянутым «Жигулям» выбили стекло, вытащили все сиденья и насрали внутри). Оказывается, что модель мира, состоящего из «сущностей» или «субстанций» не вполне адекватно позволяет описывать все это. Например, «сущности» убивает классический пример из все той же греческой философии — «корабль Тесея». Жители Афин поставили корабль, на котором Тесей вернулся с Крита, победив Минотавра, на «вечную стоянку» — как крейсер «Аврора». При этом они его постоянно ремонтировали (как крейсер «Аврора»), и наконец, настал момент, когда все досочки и гвоздики были поменяны (ну точно «Аврора»). Можно, конечно, ввести дополнительную сущность — например, ПТС, где отражать все замены номерных агрегатов — но древние греки до этого не дошли, и более-менее приемлемо парадокс разрешил Аристотель, рассматривая «субстанции» — грубо говоря то, что остается от предмета, если его лишить всех свойств. «Субстанция» нематериальна, и с точки зрения Аристотеля, сохраняется даже при замене всех «материальных» частей.

Так или иначе, но современное ООП предлагает смотреть на мир, как на множество объектов-субстанций, которые имеют изменяющиеся со временем свойства. В аристотелевскую картину мира укладывается и понятие наследования вместе с «общими» категориями объектов — как существование более общих, «вторичных» субстанций и свойств — но не все гладко с отношениями — для них приходится вводить дополнительные свойства объектов (например, у автомобиля есть свойство «владелец») — и с изменениями — фактически предложенное Аристотелем решение предлагает учитывать изменения, как какие-то новые «частицы» в картине мира.

Если непонятно про Аристотеля — то вот более «жизненный» пример. Используемая в проектировании баз данных модель «сущность-связь» (entity-relationship, или ER-модель) возникает как раз при использовании «сущностей» или «субстанций». Отношения (или «связи») в ней предлагается представлять в виде дополнительных атрибутов объектов или же (в случае отношения «многие-ко-многим») — строить «фиктивную» таблицу, представляющую отношения. Эти решения точно так же вводят в картину мира новые «элементарные частицы», которые существуют наравне с «настоящими», но ничего «реального» не представляют.

В книге предлагается принятую в современном ООП аристотелевскую модель последовательно перестраивать, приводя ее к «истинно объектному», по мнению автора, виду — в отличие от понимания «объектов» в современном ООП. Как один из «промежуточных» шагов рассматривается «логическая» модель. Вместо атрибутов предлагается рассматривать принадлежность к классам (не в смысле «обычного» ООП) — например, вышеупомянутые «Жигули» Ивана Ивановича можно отнести к классам «автомобили», «все белое», «все ржавое» и так далее. Для того, чтобы представлять отношения, в картине мира появляются «кортежи» (tuple), которые, как и индивидуальные предметы, могут входить в какие-то классы. Например, пара <Иван Иваныч, ржавые Жигули> входит в класс, который можно назвать «владеет» — равно как и пара <Иван Иваныч, участок в 6 соток за 101 километром>. Точно так же можно представлять отношения из многих элементов — например, «Иван Иваныч выписал любимому внуку доверенность на «Жигули»» можно представить тройкой <Иван Иваныч, любимый внук, Жигули>, входящей в класс «кто-то выписал кому-то доверенность на что-то». Всякий же объект оказывается представителем универсальной категории «логических объектов».

Важное новшество в этой модели — возможность рассматривать «классы объектов» с позиции теории множеств. «Класс» — это множество объектов, которое само может являться подмножеством другого класса. Примером такого взаимоотношения между классами можно назвать цвета — класс «все раскрашенное» содержит классы «все белое» и «все красное» как подмножества. Это позволяет рассматривать иерархии классов, более точно отражающие реальный мир, чем в случае других моделей. Некоторой сложностью в главе про логическую модель оказывается понимание автором теории множеств. Например, если множество «всех красных» объектов — это объекты A и B, а «всех белых» — Y и Z, то описанный выше класс «всего раскрашенного» будет содержать не два описанных класса, а четыре объекта A, B, Y и Z. При этом автор использует термин «member of» — то есть описывает множество {{A, B}, {Y, Z}} вместо {A, B, Y, Z}.

Кстати, с помощью логической модели можно проектировать реляционные базы данных. Да, они получаются сложнее, чем в книжке «PHP и MySQL для чайников» — но понимание того, что таблица БД — это список кортежей, входящих в какое-то отношение (поэтому БД и «реляционная»), а не «записей об объектах», позволяет представлять многие вещи куда эффективнее. Фактически это обобщение принципов, заложенных в ER-модель на отношения с количеством членов, большим двух.

Логическая модель снимает сложности с отношениями, но проблема представления изменений остается. Для ее решения предлагается ввести «четвертое измерение» — время, и вместо локализованных во времени «логических объектов» рассматривать объекты на протяжении всего их жизненного цикла. Фактически, это замена значения функции на саму функцию или ее график, то есть некоторую кривую — очень плодотворная идея в математике и, как ни странно, в науке о представлении окружающего мира. Эту модель автор называет «объектной» — в очередной раз вворачивая модное слово и совершенно смущая читателя — особенно того, который обнаружил в главе о «субстанциальной» модели все понятия современного ООП.

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

После последовательного построения «объектной» (в терминологии автора) модели она применяется к нескольким примерам, разумеется, весьма успешно. Построенная методология преобразования «сущностных» моделей в «объектные» называется красивыми словами REV-ENG™ (да-да, именно со значком trade mark), предлагается автором в качестве абсолютно универсальной и везде-везде применимой. Насчет абсолютной ее применимости не знаю — хотя очень похожий метод лежит в основе стандарта обмена данными ISO 15926, и по утверждениям все того же [info]ailev, это «наше все» и вообще, будущее человечества. Во всяком случае, книжка круто «расширяет сознание» и заставляет по-новому взглянуть на привычные вещи.

PS Несмотря на то, что я поставил тег «программирование», в книге нет ни единой строчки кода ни на одном из языков программирования. Читать можно всем без исключения, хотя очень желательно понимание существующих методов работы с разнообразными данными — хотя бы в рамках UML и того, что называется «теорией баз данных».

Business Objects: Re-Engineering for Re-Use, или кому не хватает ООП: 12 комментариев

  1. Чо-то судя по твоему описанию книжка так себе.

    >в картине мира появляются “кортежи” (tuple), которые, как и индивидуальные предметы, могут входить в какие-то классы
    Вроде в нормализованной реляционной базе так и должно происходить?

    >иерархии классов, более точно отражающие реальный мир
    Само по себе, это не является хорошим или плохим.
    Это слишком далеко от практики: обычно люди программируют не для «описания реальности», а для решения каких-то задач.

    P.S. Из относительно недавно прочитанного по теме, мне больше всего понравилась книжка David West, Object Thinking (MS Press, 2004).

    1. > Вроде в нормализованной реляционной базе так и должно происходить?

      Нормализованность не имеет никакого отношения к тому, как содержимое БД интерпретируется. Тут главное отличие в том, что обычно (например, нарисовав ER-диаграмму и построив по ней набор таблиц) мы понимаем строку таблицы, как описание какой-то сущности с ее свойствами. Чисто терминологически это можно назвать «кортежем» — но строка таблицы типа

      «п666ох50, ВАЗ-2101, белый, ржавый, не на ходу»

      представляет собой не описание отношения из пяти элементов (для чего, собственно, реляционная модель и придумана), а описание объекта с какими-то свойствами.

      > Само по себе, это не является хорошим или плохим.

      Согласен, но с одной оговоркой. В таком случае ООП должно «отказаться от претензий» на то, что представляет собой универсальный способ для описания действительности.

      > для решения каких-то задач

      Решение любой задачи требует описания некоей «предметной области» (которое сейчас почти повсеместно делается на ООП-языке). Есть такие задачи, где требуется более точное описание — для чего и придумали ISO 15926.

      > David West, Object Thinking

      Проглядел по диагонали. Если выкинуть половину книжки, где концентрация слов XP и Agile зашкаливает, то останется краткое описание «объектного метода» в духе любой нормальной книги по той же теме. Как говорил халиф Омар, сжигая Александрийскую библиотеку, «Если эти книги содержат то же, что содержит Коран — они бесполезны.»

  2. > В таком случае ООП должно “отказаться от претензий” на то, что представляет собой универсальный способ для описания действительности.
    А оно «претендует»?

  3. «класс “всего раскрашенного” будет содержать не два описанных класса, а четыре объекта A, B, Y и Z. При этом автор использует термин “member of” – то есть описывает множество {{A, B}, {Y, Z}} вместо {A, B, Y, Z}»

    Что-то Вы тут запутались.

    Класс “всего раскрашенного” будет содержать четыре объекта A, B, Y и Z. Его членами “members” являются все цветный объекты {A, B, Y, Z}.

    Класс “цвет” будет содержать два описанных класса. Его члены “members” — красный и белый {{A, B}, {Y, Z}}.

    Именно так и используются термины теории множеств у Партриджа, никакого противоречия с математикой.

  4. > Для того, чтобы представлять отношения, в картине мира появляются “кортежи” (tuple), которые, как и индивидуальные предметы, могут входить в какие-то классы…
    В чистом виде описана реляционная модель данных. Интерпретация кортежей как «сущностей» в РМД — удел безграмотных, т.к. корифеи РМД, например, К. Дейт давно говорят о том, что кортежи отношения представляют собой факты (истиностные высказывания). Каждой переменной отношения соответствует предикат, аргументами которого являются атрибуты. Каждый кортеж содержит значения атрибутов, про которых предикат переменной отношения вычисляется в истину. Реляционные базы данных — это совокупность высказываний и правил. Результаты запросов — теоремы. Процесс вывода результатов запроса есть процесс доказания теоремы. Никаких «сущностей» в РБД нет.

    1. > В чистом виде описана реляционная модель данных

      Это она и есть — не хватает только операций реляционной алгебры.

      > удел безграмотных

      И тем не менее для проектирования БД вовсю используется ER-модель, где первичны сущности, а связи — это так, ерунда. В большинстве книг нет даже упоминания о том, что разница между ними не так велика.

      > Никаких “сущностей” в РБД нет.

      — Видишь суслика? — Нет… — Я тоже не вижу. А он — есть!

      1. > для проектирования БД вовсю используется ER-модель
        Верно. Но понятийный аппарат ER-модели и относится к ней, а РМД тут не при чём. Тем более, что вы правы, говоря о том, что разница между «E» и «R» не так велика. основной претензией к ER-модели как раз и является неопределённость понятий «сущность» и «связь», приводящая на практике к тому, что одно и то же можно зачастую представить как сущностью, так и связью. Например, брак между людьми в одном случаем может быть связью, в другом — сущностью. В РМД такой вопрос вообще отсутствует. Там только факты и ограничения (правила). Внесение в понятийный аппарат РМД понятия «сущность» только всё портит, так как этим сразу привносится неопределённость. То есть плюса нет, а жирный минус есть.

        Кстати, забыл сказать, что вы в статье оговорились, написав «таблица БД – это список отношений». Уверен, ваы не хуже меня знаете, что таблица БД – это и есть отношение (а точнее, таблица есть некоторое представление отношения). Подправьте. С уважением, Евгений.

  5. Любопытно. Какое-нибудь готовое решение (фреймворк или даже язык), где такой подход используется, уже есть?

    1. Зачем? Многие еще с ООП путаются, а простую и понятную логическую модель заменяют слегка модифицированной сущностной (в смысле ER-моделью) — и это в лучшем случае.

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

      То, что предлагает Партридж — это основа стандарта ISO 15926, как я понимаю, [info]ailev как раз и занимается разработкой ПО, этот стандарт поддерживающего. Есть более современные разработки, использующие этот подход, например, язык Gellish. Это не язык программирования, это язык «онтологического моделирования», то есть описания структуры некоей системы, кстати, довольно близкий к естественному.

      Очень интересно «рекурсивно» походить по ссылкам из этой записи:

      http://ailev.livejournal.com/1024334.html

    2. Ну простой ответ на этот вопрос — графовые языки, и RDF с Семантическим Вебом. Они под этот подход прямо заточены. Но применять его не требуют. То есть полный ответ — если вы хотите работать с RDF, то понимание логического и объектного подходов есть ваш единственный шанс не превратить всё в помойку данных.

      Для чего это пригодно, какие даёт выигрышы — предмет религиозных войн.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *