Шура Люберецкий

По наводке 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, и по утверждениям все того же ailev, это «наше все» и вообще, будущее человечества. Во всяком случае, книжка круто «расширяет сознание» и заставляет по-новому взглянуть на привычные вещи.

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

Неспешно читаю-решаю упражнения из SICP. Дошел где-то до середины книги, так что могу написать какое-то более развернутое мнение.

Начну с плюсов. Как недавно заметил infowatch, в «околокомпьютерных» областях достаточно велико количество самоучек, а «официальные» учебные планы зачастую неадекватны — следовательно, любой более-менее приличный «компьютерщик» в той или иной степени оказывается «самоучкой». Недостатки такого подхода очевидны — нет «систематичности» знаний и «единой картины мира».

Вообще, складывается такое впечатление, что отечественное программирование во многом представляет собой некий «карго-культ», копирующий внешние стороны такового в США. Кто-то рассказал про интервью при приеме на работу в Google и Microsoft — и все-все-все, включая распоследнюю «веб-студию», бросаются спрашивать про сортировку и красно-белые деревья. То, что когда-то эти вопросы позволяли Google и Microsoft набирать исключительно студентов-отличников ведущих американских ВУЗов — в расчет не принимается. Аналогичное впечатление производят и учебные планы — например, вопросы, связанные с индуктивными вычислениями и прочей рекурсией явно заимствованы из курсов с использованием Lisp наподобие SICP. На «традиционных» у нас C и Pascal они выглядят довольно дико. В общем, самоучки учат самоучек.

Что делать в такой ситуации? Наверное, лучше всего «забить» на попытки Рабиновича напеть Паваротти и «самоучиться» по первоисточникам — тем более, что ситуация с ними сегодня лучше, чем десяток лет назад. Например, SICP достаточно неплохо переведена, и теперь не придется вычленять «разумное, доброе, вечное» из кривого пересказа. Не надо «плеваться» от того, что эта книга — всего лишь «вводный курс» программирования. В свое время, например, кто-то обратил внимание на возраст присутствующих в аудитории на видеолекциях (в интернете выложены видеозаписи лекций по этому курсу) — и там было немало вполне взрослых людей, возможно даже и с опытом работы.

Более того, из-за особенностей применяемого диалекта Lisp, в SICP уже в конце первой главы переходят к вполне содержательным задачам — то есть демонстрирующим не какие-то конструкции языка, а различные подходы к программированию. Это отличает ее от других «вводных курсов», где берется какой-то язык программирования (раньше дико модным был Pascal), подробно изучаются его конструкции, а из «программирования» до обучающихся доводится лишь одна истина — что, оказывается, можно набрать на клавиатуре какой-то текст, затем нажать нужные кнопки и компьютер волшебным образом выполнит то, что хотел программист.

Что меня особенно удивило — я ни разу не видел более краткого описания ООП, чем один-единственный абзац в SICP (в начале 3 главы):

Существует мощная стратегия разработки, которая особенно хорошо подходит для построения программ, моделирующих физические системы: воспроизводить в структуре программы структуру моделируемой системы. Для каждого объекта в системе мы строим соответствующий ему вычислительный объект. Для каждого действия в системе определяем в рамках нашей вычислительной модели символьную операцию. Используя эту стратегию, мы надеемся, что расширение нашей модели на новые объекты или действия не потребует стратегических изменений в программе, а позволит обойтись только добавлением новых символьных аналогов этих объектов или действий. Если наша организация системы окажется удачной, то для добавления новых возможностей или отладки старых нам придется работать только с ограниченной частью системы.

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

Разумеется, что все рассматриваемые в SICP подходы к программированию можно показать и с использованием других языков. Например, встречаются решения задач оттуда на Common Lisp (это, правда, не считается — так как он все равно достаточно близок к Scheme), Python, Javascript и даже на C# — в общем, «на чем угодно». Правда, ни один из этих языков (за исключением, разве что, Common Lisp) не подходит для того, чтобы продемонстрировать все эти подходы сразу.

Теперь к недостаткам — благо «хвалебных» отзывов о SICP и без меня предостаточно. Можно было бы начать с классического «Не покупайте эту книгу«, но у меня к SICP другие претензии. Меня, как математика, поражают вольности с численными методами. Любой программист считает себя непревзойденным специалистом в этой области — но это далеко не так. Не последнее место в формировании этого заблуждения занимают книги по программированию, в которых численные методы рассматриваются в отрыве от их «содержания», как обычные алгоритмы.

Например, в главе 1.3.1 приводятся формулы численного интегрирования, и утверждается, что «определенный интеграл … можно численно оценить с помощью формулы» («the definite integral … can be approximated numerically using the formula «) — при этом не раскрывается ни законность этой оценки (что можно «простить»), ни ее точность. Правда, вычисляются два приближения для одного интеграла, меньшее значение переменной dx соответствует большей точности — и только! В упражнении 1.29 приводится формула Симпсона, утверждается, что она представляет собой «более точный метод численного интегрирования» (в чем эта точность заключается — не объясняется), а затем предлагается проинтегрировать с ее помощью кубический многочлен — якобы это должно «доказать», что она «более точна». Удивительно, но результат оказывается ближе к истинному значению — но это не сходимость, как в первом случае, а просто свойство формулы Симпсона — она дает точное значение при интегрировании кубических многочленов.

Чуть дальше появляются более «страшные» вольности. Например, в «определении» производной (оно необходимо для метода Ньютона) предлагается заменить стремящееся к 0 dx каким-то «очень малым» значением. Сказать, что это приближение, видимо, религия не позволяет.

В конце раздела 1.3 находим упражнение 1.45 — от которого я пришел в ужас. Сообщается, что метод Ньютона не работает для некоторых функций, например, для извлечения корня n-й степени. Предлагается использовать многократное «торможение усреднением» (average damping — этот термин я не встречал нигде, кроме SICP), а «кратность» его применения установить — держитесь — экспериментально! Да, читатель SICP, скорее всего, не сможет доказать полученное утверждение — но предложение «экспериментально» доказать математическое утверждение, согласно современным представлениям, дико само по себе. Может, не стоит вообще давать такие задачи?

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

Продолжение, как говорится, следует.