Философия ООП. Начало

[Olegator]

Статья
При прочтении этой статьи меня больше всего заинтересовали такие слова:
1. "алгоритм управляет данными"
2. "данные управляют алгоритмом" - информационная модель.
Как я понял и структурное и ОО программирование позволяют реализовать оба этих варианта. Только второй вариант проще реализуется с помощью ООП. И за счёт того, что второй вариант сейчас более востребован, ООП тоже более востребован.
Если это так, то возникает вопрос почему ООП проще для создания информационной модели.

[Dimka]

Примечание по поводу "данных, управляющих алгоритмом".

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

Говорить о том, что нечто проще реализуется в том или ином случае только из-за существа подхода, нельзя. Простота реализации зависит как от существа поставленной перед программистом задачи, так и от существа применяемого подхода к решению этой задачи. Например, алгоритмы численных расчётов явно не улучшатся по своему существу, если их переписать с использованием объектного подхода. Каждый алгоритм всё равно будет решать ту узкоспециальную задачу, для которой он создан. И в рамках структурного подхода программист может создавать произвольные математические структуры и операции над ними в виде отдельных процедур и функций и создавать библиотеки этих структур данных и подпрограмм их обработки. Примером может служить обширный библиотечный фонд алгоритмов, реализованных в течение десятков лет на FORTRAN. С другой стороны, реализация информационной модели, предназначенной в первую очередь для модификации и развития себя самой, расширения своих свойств в процессе разработки прикладных решений на основе этой модели, явно пострадает в случае отказа от использования ООП. До сих пор в порядке анекдота ходит быль о программе "Hello world!" из SDK для Windows 1.0, занимавшей целых 150 строчек кода и ещё 20 строчек файла ресурса. Хотя впоследствии все эти многочисленные строчки, требуемые WinAPI (написанном на C без использования ООП), были упакованы в различной степени элегантности объектные библиотеки, и теперь "Hello world!", написанная с помощью лучших библиотек, занимает на порядок меньше строк кода и, соответственно, более "читабельна" для программиста. Впрочем, это уже вопросы истории развития основных свойств объектных программ (например, инкапсуляции), и о том речь впереди.

Ответ на вопрос вытекает из свойств конкретной информационной модели. Во-первых, всякая информационная модель есть модель - гносеологический заместитель оригинала (т.е. модель адекватно отражает наши знания о некотором оригинале - явлении, процессе, объекте, другой модели). Всякая модель не в полной мере замещает оригинал, а лишь в той степени и с той точки зрения, которые нужны создателю модели по некоторым его прагматическим соображениям - это свойство упрощающей идеализации оригинала в сознании создателя модели. Информационная модель содержит в себе некий упрощённый аналог информации о структуре и поведении оригинала; инструментом работы с информационной моделью является какой-либо язык. Если оригинал является процессом, имеющим простую неизменную структуру, его удобно описать в виде алгоритма - чёткой последовательности операций над данными ("алгоритм управляет данными"). Например, в области численного моделирования процессов, описываемых системами дифференциальных уравнений, применение структурного программирования достаточно удобно: изменение значений некоторых независимых параметров процесса производится извне (возможно, по какой-либо программе), и на основании этих управляемых пользователем параметров при помощи алгоритма(ов) рассчитываются значения зависимых параметров системы. Однако оригинал в виде такого процесса - это лишь частный случай. Другие виды оригиналов требуют описания в модели сложных, изменяемых со временем свойств объектов, структурных отношений, и поведение модели зависит от этих отношений ("данные управляют алгоритмом"). Например, модели поведения системы с переменным количеством активных элементов с дискретными внутренними состояниями и переменными зависимостями между элементами - такие модели встречаются в описании производственных процессов, управления транспортными потоками в сильно разветвлённых сетях и т.д. Для таких моделей (особенно, имеющих множество синхронно протекающих процессов) понятие алгоритма практически не применимо. ОО подход прямо на уровне языков программирования позволяет явным образом описывать как элементы таких моделей, так и поведение этих элементов (включая динамическое изменение свойств).

Ещё раз обращу внимание на фразу из статьи:

В течение 1990-х годов изменилось мышление многих программистов, появилось новое видение проблем и, соответственно, принципиально новые постановки задач в программировании.

(90-ми годами датирована массовость этого процесса, а первые идеи появлялись ещё в 60-70-х годах.)

Нельзя сказать, что процесс шёл лишь в направлении от постановки сложных задач к выработке нового подхода к их решению. Хорошее владение подходом, овладение новым языком (системой понятий) порождает и обратный процесс - появляются новые задачи, не выражаемые (или трудно выражаемые) в старых понятиях. Каждый подход хорош для решения своего класса задач.

[Alf]

...
2. «данные управляют алгоритмом» - информационная модель.
Как я понял и структурное и ОО программирование позволяют реализовать оба этих варианта. Только второй вариант проще реализуется с помощью ООП.

Нашел в списке литературы книгу, о которой говорил тебе: Jackson, Michael. Principles of Program Design. - New York, Academic Press, 1975. В ней приводится весьма оригинальная технология разработки программ, в которой структура программы полностью определяется структурой обрабатываемых данных. Даже предложена формальная процедура, позволяющая выводить одну структуру из другой. Само собой, ни о каком объектном подходе в то время и речи не было, тем более в промышленном программировании.

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

Вывод: я бы не стал проводить границу между структурным и объектным программированием по принципу "алгоритм первичен - данные вторичны" или наоборот. Эта проблема сродни проблеме курицы и яйца. Нужно сечение проводить в другой плоскости.

[Dimka]

структура программы полностью определяется структурой обрабатываемых данных.

Поясни, это относится только к статической структуре программ (например, группировка структур данных и процедур с функциями в тематические пакеты), или в том числе затрагивает динамику работающей программы (когда выбор той или иной процедуры происходит автоматически во время исполнения на основании фактического типа данных или фактического значения)?

Уж не о том ли Джексоне речь, чьим именем называются метод проектирования и графический язык структурной декомпозиции программ (вроде бы даже в Visio такие диаграммы есть)?

[Dimka]

Если речь о том Джексоне, то, например, здесь ( http://www.interface.ru/fset.asp?Url=/case/defs72.htm ) дан краткий обзор его принципов структурного проектирования (на русском).

[Alf]

Поясни, это относится только к статической структуре программ

Да, в книге шла речь о построении статической структуры программ в соответствии со структурой обрабатываемых данных. Детали уже подзабыл, дело без малого 20 лет назад было. Основные идеи запомнились такие: для обработки массива - цикл с пересчетом, для обработки последовательности записей вроде списка или файла - цикл с пред/постусловием, для обработки записи с вариантами - условный оператор/выбор, для обработки неоднородной записи - последовательность. Получалось, что если расписать структуры входных, выходных и промежуточных данных, из них следовала структура типовой программы их обработки (считать входные данные, обработать, сформировать выходные данные). Конечно, не панацея на все случаи жизни, но рутинные задачи прекрасно в эту картину укладывались, а побыстрее отделаться от таких - мечта программиста.

Уж не о том ли Джексоне речь, чьим именем называются метод проектирования и графический язык структурной декомпозиции программ (вроде бы даже в Visio такие диаграммы есть)?

Не могу с уверенностью сказать ни "да", ни "нет", - Джексонов по ту сторону кордона немногим меньше, чем Ивановых по эту, так что всякое возможно. Насчет диаграмм Джексона в Visio - визуально графические элементы не слишком похожи на те, что помнятся мне из книги. Но, с другой стороны, упомянутся мной книга издана в 1975 году, а публикации относительно метода Джексона мне попадались датированными 1983 годом, почти десятилетием позже. Так что либо за 10 лет другой Джексон появился, либо наш старый переработал свою методику. Оба варианта вполне вероятны, ведь тот же нынешний UML не слишком погож на диаграммы, предложенные Бучем в ранних работах.

[Dimka]

Да, речь о том Майкле Джексоне, который упомянутую выше книгу написал. Как я вижу, впоследствии он выработал некоторые другие принципы, назвав их JSP (Jackson Strucutred Programming) и начал продвигать идею использования CASE-средств (Jackson Workbench) для структурного проектирования программ (и, фактически, программирования через проектирование, т.к. его CASE-средства предполагают автоматическую генерацию кода программ).

Между тем в его диаграммах явно заложено понятие алгоритма. Как тут один преподаватель пишет в статье о практике использования JSP: "The result of applying JSP is a program that reflects problem structure as expressed in a model of its inputs and outputs." Т.е. структуру программы он воспринимает как дкомпозицию большого чёрного ящика на цепочки связанных более мелких чёрных ящиков, у которых известны входы, выходы и их функциональное назначение. Структурам потоков данных между этими процессами уделяется второстепенное значение, а это не то, о чём я говорю - не всегда такой подход удобен.

Что же касается типовых структур данных и алгоритмов их обработки, то не могу согласиться с тем, что структуры данных "массив" или "запись" определяют алгоритм их обработки. Потому что разные алгоритмы могут обрабатывать одну и ту же структуру данных. А вот для алгоритма (как последовательности известных исполнителю операций, а не как следствия свойств объектов) подать на вход произвольную структуру данных не получится - ему нужна конкретная структура данных, для которой он реализован. Поэтому, по-моему, всё же в данном случае алгоритмы определяют структуры данных.

Приведу пример.

Возьмём довольно просто реализуемую в ООП концепцию алгоритма foreach для элементов коллекции. Имеется абстракция коллекции как последовательности некоторых элементов, создаётся абстрактный итератор с примерно следующим интерфейсом: флаг "достигнут конец коллекции", операция "перейти к следующему элементу", операция "начать с начала". Для каждого типа коллекции (массив, связный список, бинарное дерево, хэш-таблица и т.д.) создаётся ассоциированный с конкретным типом коллекции конкретный тип итератора. А собственно алгоритм (т.е. его шаблон) прост:

1) итератор."начать с начала"
2) пока не итератор."достигнут конец коллекции" делать
2.1) <полезное действие>
2.2) итератор."перейти к следующему элементу".

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

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

[Alf]

В то время, когда Джексон предложил свои идеи, и слова такого не знали - "полиморфизм". Самыми популярными языками были FORTRAN-IV и PL/I, эстеты наслаждались Pascal'ем, а диссиденты видели будущее за FORTRAN-77. Собственно, и аппаратура особенно не располагала к мудреному софту - пользователю так называемых "мини-ЭВМ" (весом в несколько тонн и занимающих десятки квадратных метров) на задачу выделялось около 50 килобайт оперативной памяти, а на машинах посерьезнее нужно было выстаивать очередь на выполнение пакетного задания. Под стать инструментам были и программы - не наворотишь объектов в языке, где единственной структурой данных является массив, а единственным способом межмодульного взаимодействия - блок COMMON.

Для того времени идеи Джексона были весьма свежими. Известно, что поступает на вход (обычно это были файлы, набранные вручную или полученные в результате работы других программ - СУБД в те времена не были обыденным привычным инструментом). Известно, что требуется на выходе (зачастую это были данные, предназначенные для управления оборудованием с ЧПУ, поэтому особый произвол в выборе формата тут тоже недопустим). Остается продумать, какие промежуточные этапы должны пройти данные в процессе преобразования, - и каркас программы готов. Остается аккуратно реализовать код процедур (или подпрограмм, или как там они назывались на языках того времени).

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

Собственно, эти мемуары приведены с единственной целью - дать Olegator'у иллюстрацию, что "данные, управляющие алгоритмом" не есть синоним ООП. Не данные первичны для объекта.

[Dimka]

Не данные первичны для объекта.

Коль уж речь о философии, то можно обратиться к её истории.

Был такой философ по фамилии Декарт Картезий, известный изобретением так называемого дуализма. Мучал его вопрос о том, как человеческий разум получает адекватное представление о реальности. Или, применительно к разработанной им аналитической геометрии, почему, например, формула y=x^2 на самом деле соответствует той определённой кривой, которую рисует на бумажке геометр.

Основная идея того времени  в этом вопросе состояла в том, что разум и реальность имеют (или входят в) некую общую субстанцию, через которую разум и устанавливает связь с реальностью и может её достоверно познавать. Когда Декарт отчаялся найти эту субстанцию, он по традиции всё свалил на Бога - мол, соответствие человеческого разума реальности есть промысел божий.

Затем жил другой философ по фамилии Спиноза. Основной пафос его философии состоит в том, что никакой посреднической субстанции между разумом и реальностью нет, просто разум - одно из свойств реальности, соответственно, вопрос о достоверности познания даже теряет смысл.

(Естественно, это кратко, упрощённо и не совсем точно изложено.)

Проводя аналогию с программированием, можно сказать, что ранее, когда данными и алгоритмами оперировали как связанными в программе различными субстанциями, существовал такой декартовский дуализм, и лишь промысел программистский устанавливал между ними соответствие. Более того, требовалось постоянное программистское вмешательство. Зато теперь есть такая субстанция, как объект - данные (и классы объектов как типы данных), и свойством объекта является его поведение, реализованное подчинёнными и входящими в состав объекта отдельными операциями и алгоритмами.

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

[Alf]

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

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

Впрочем, сколько людей - столько и разных философий, спор тут неуместен. Кому-то ближе моя точка зрения, кто-то предпочтет видеть в объектах усовершенствованные структуры C (каковыми их и замыслил Страуструп). Главное тут - позволяет ли данная философия сделать практически полезные выводы или сводится к традиционному для большинства философов словоблудию. Например, Декарт Картезиевич помимо вороха туманных идей обогатил науку прямоугольной системой координат, за что ему большое спасибо. Одна она лично для меня стоит тонны фолиантов красивых запутанных фраз со ссылками на переписку Конфуция с Навуходоносором.

[Dimka]

В прошлом учебном году кафедра "осчастливила" меня книжкой В.Э. Вольфенгагена "Методы и средства вычислений с объектами. Аппликативные вычислительные системы", М.: 2004, в которой, как в аннотации отмечено, "систематически рассмотрены модели, методы и средства, для которых центральной сущностью является представление об объекте".

Цитата из этой книжки:

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

С позиций первого из них объект трактуется через выделяющие его свойства, то есть, по сути, принимается, что объект есть некоторая совокупность свойств, а ещё лучше - некоторое отношение, установленное на свойствах.

Во втором в качестве объекта принимается некоторая правильно построенная абстрактная сущность.

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

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

информационная модель совмещает в себе декларативность описания элементов модели + объектов и императивность описания операций, выполняемых над объектами + объектных методов.

Я сторонник уточнения того уровня абстракции, на котором формируется то или иное понимание объекта.

На нижнем уровне абстракции - в упомянутом смысле Страуструпа - объекты можно рассматривать как расширение смысла структур - привязка операций обработки данных к данным (если идти от данных) или привязка данных к операции их обработки (если идти от алгоритма). На этом уровне мышление программиста ещё не ушло от смысла программы, придаваемого ей структурным подходом.

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

Однако конкретная динамика программной системы зависит от структуры программной системы, в частности, архитектуры. Логическая структура программ в структурном подходе в период высшего своего развития создала понятия модуля или пакета (в смысле языков Modula, Ada). Такая логическая структура в хорошей программной системе соответствует семантике системы (вопросы модульного проектирования кратко описаны в тексте по ссылке из поста #4). Однако эта организационная структура алгоритмов и данных не составляет с этими алгоритмами и данными единого целого. Она больше нужна программисту, нежели среде исполнения программы (например, операционной системе).

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

На высшем (на данный момент) уровне абстракции у объектов выделяются новые их свойства. И вот к чему я упомянул в начале книжку Вольфенгагена и напомнил об императивных и декларативных программах. Если объекты рассматривать как абстрактные сущности, то на логических структурах этих объектов возможно выполнение вычислений в непривычном для многих объектных программистов смысле. Логическую структуру объектов можно воспринимать как декларативную программу, типы элементов которой обладают семантикой, определённой предметной областью. Известны логические отношения между этими элементами (разновидности ассоциации и обобщение). К такой программе можно применить некоторую машину редукции как во время программирования, так и во время исполнения программной системы. В книжке Вольфенгагена в качестве базовых формализмов выбраны лямбда-исчисление и комбинаторы, поэтому понятие "вычисление" в основном рассматривается как операция редукции. Благодаря этому подходу программистский стереотип организации вычисления на основе императивного алгоритма вообще исчезает из обсуждения, и програмист получает единую основу осмыления объекта на среднем и высшем уровнях абстракции, а также обретает возможность "безболезненно" переходить между этими уровнями абстракции.

Простая редукция в настоящее время уже выполняется в объектных программах во время исполнения, когда за указателем на объект абстрактного типа-предка может скрываться объект конкретного типа-потомка - свойство полиморфного поведения объекта, и программа автоматически определяет, с каким конкретным объектом имеет дело. Программист может описать абстрактный алгоритм, однако во время исполнения этот алгоритм "редуцирует" к некоторому конкретному алгоритму в конкретный момент времени исполнения. Пример я приводил в посте #6. Для этих же программ во время программирования выполняется обратная редукция - наследование свойств ранее определённых объектов в новых объектах.

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

Уже лет 20 назад была реализована концепция программирования и исполнения программ в Smalltalk-средах разработки, когда не различаются границы между режимами программирования и исполнения, между приложениями и средой. Программист в процессе исполнения программы может править исходный код или (что то же самое) в процессе программирования исполнять написанное. Прикладная программа является непосредственным развитием системной среды (прикладные классы добавляются в общий репозиторий классов системы).

Развивая этот подход и учитывая направления развития объектного подхода, если создать удобное представление (сейчас - отображение на экране) понятий предметной области для пользователя, в перспективе пользователь сможет самостоятельно создавать приложения в рамках рабочей информационной модели. Современными недоразвитыми примерами такого подхода являются разнообразные САПРы (CAD'ы). Естественно, это не избавит пользователя от необходимости думать. (Обсуждение этого вопроса поднималось в темах "Разговор ни о чём", "Поговорим за ЛЕС", "ЛЕС-2" и "ЛЕС-3", доступных в Кунсткамере . )

[Alf]

Небольшой вопрос чуть в сторону от темы.

Является ли данный курс лекций развлекательным или обязательным? Другими словами, могут ли студиозусы безнаказанно игнорировать его, или же несдача зачета (или, паче чаяния, экзамена) может стать серьезным препятствием на пути к обзаведению дипломом?

[Dimka]

Является ли данный курс лекций развлекательным или обязательным?

О курсе лекций речи не идёт. Речь идёт о единичной лекции в рамках обзорных курсов (что называется, для "общего развития") "Технологии программирования" и "Теория разработки программного обеспечения". Читается лекция, в конце её идёт свободное обсуждение темы со студентами, и всё. Естественно, никаких "догматов веры" на экзаменах - технический вуз не является духовной семинарией . Задача - научить студента самостоятельно работать головой, а не вбить ему в голову систему убеждений. Какие из собранных им мнений по разным вопросам он будет использовать в своей последующей работе - это его дело. В курсе "ОО программирования" объекты рассматриваются на нижнем и среднем уровне (в смысле вышеописанного) абстракции + небольшим обзором отдельные элементы проектирования архитектур (более подробно проектирование рассматривается в специализированном курсе).