В.Ш. Кауфман - Языки программирования - концепции и принципы (1990) (1160787), страница 78

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 78)

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

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

Однако при определенных ограничениях на класс сообщений возможна весьма

глубокая оптимизация (в перспективе с учетом конкретизирующего

программирования). Во всяком случае прямой вызов операций по статически

известным именам - частный случай обмена сообщениями.

По убеждению автора, объектная ориентация знаменует и стимулирует

принципиально новый уровень развития средств программирования (ЯП в

частности) потому, что позволяет естественно сочетать практически все

рассмотренные нами (и некоторые иные) перспективные тенденции, тем самым

создавая почву и для следующего витка развития (полезно в этой связи

обратить внимание, например, на идеологию ЯП Оккам-2 с его асинхронными

процессами-объектами и каналами для обмена сообщениями). Рассмотрим коротко

представляющиеся наиболее интересными проблемы вместе с идеями их решений в

рамках объектно-ориентированного программирования. Для краткости его понятия

и решения будем предварять префиксом "о-".

1. Проблема управления.

Основной о-ответ - децентрализация управления. Вместо представления о

едином исполнителе, выполняющем единую программу, создаваемую единым во

многих лицах "богом"-программистом, предлагается мыслить в терминах

коллектива (коллективов) взаимодействующих объектов-исполнителей, "живущих"

в значительной степени самостоятельно (с точностью до о-взаимодействия) в

соответствии со своими собственными правилами поведения и "о-социальными"

ролями. Создание, т.е. программирование такого о-общества также следует

представлять как довольно демократическую скорее историю, чем процедуру,

существенно использующую развиваемость о-индивидов (как типов, так и

объектов), а также относительно локальные договоренности о конкретных

способах взаимодействия. Такую тенденцию можно обозначит метафорой "от

автархии к анархии", в связи с чем рассматриваемый стиль программирования

можно назвать "анархо-ориентированным", если в соответствии с современными

воззрениями снять с понятия "анархия" привкус априорного неприятия.

2. Проблема взаимодействия.

Основной о-ответ (в перспективе) - относительно локальное

взаимопонимание на основе взаимоприемлемого языка сообщений, совершенно не

обязательно единого и понятного для всех. Более того, глубина понимания

конкретных сообщений участниками взаимодействия также может легко

варьироваться в зависимости от их роли в решении совместных задач.

3. Проблема ресурсов.

Основной о-ответ - разнообразие как самих ресурсов, так и способов их

создания, предоставления и изъятия по соответствующим операциям-запросам-

сообщениям соответствующими объектами. В принципе в эту схему укладываются

любые мыслимые варианты и их оптимизации.

4. Проблема развития.

Основной о-ответ - идеал наследуемости. Однако в общей перспективе его

следует дополнить динамизмом (вплоть до построения обогащенных объектов при

работе других объектов), сближением понятия модуля с понятием объекта

(объектного типа, класса), а также наследуемостью в языке обмена

сообщениями.

5. Проблема защиты.

Основной о-ответ - идеал наследуемости. Однако и здесь следует его

дополнить динамизмом при контроле корректности сообщений, а также в общем

случае принципиальной невозможностью разрушить объект, если соответствующий

приказ-сообщение не входит в согласованный язык сообщений.

6. Проблема классификации (типизации).

Основная метафора о-ответа - тип = язык. Эту метафору можно раскрыть и

так, что типизация охватывает любые языковые конструкты (данные, операции,

их сочетания - это путь к универсальному конструктиву типа [28]), и так, что

средства описания типа тесно переплетается со средствами определения полного

языка (ведь при определении типа объектов нужно определять и воспринимаемый

ими язык сообщений). Одно из "экстремистских, но не лишенных смысла

толкований - к одному типу относятся объекты, "понимающие" определенный язык

(или подъязык), обеспечивающий их взаимодействие. [Так недалеко и до

объектной нации.]

7. Проблема модульности.

Общий о-ответ - модуль = объект (объектный тип). Существующие различия

между этими понятиями связаны с особой ролью трансляции в жизненном цикле

программы. Необходимость анализа и интерпретации сообщений в качестве

аспектов функционирования объектов превращает трансляцию в одну из рядовых

операций и тем самым сближает логическую структуру программы с ее физической

структурой.

8. Проблема свободы.

Проблема свободы и ответственности естественно возникает перед каждой

творческой личностью, в том числе и в весьма острой форме - перед

программистом. Поскольку объектная ориентация - специфический стиль

программистского мышления, а также определенная совокупность средств

программирования, предоставляемая ЯП, интересно понять, какие ответы

возможны в ее рамках.

Известно, что свобода хороша до тех пор, пока она не ограничивает

свободу индивида, претендующего на тот же уровень свободы. С этой точки

зрения основной о-ответ - единственным источником любых ограничений на

свободу поведения объекта служит требование взаимопонимания (корректного

обмена сообщениями) со всеми, кто ему самому необходим (для выполнения о-

социальной" роли). Частным случаем такого требования служат и ресурсные

ограничения, поскольку в общем случае ресурсы по требованию объекта

предоставляются ему другими объектами. Другой частный случай - описание

характера обмена сообщениями-операциями в спецификации и полная свобода

реализации при условии воплощения требований спецификации.

Таким образом, объектная ориентация действительно в максимальной

степени способствует свободному сочетанию самых разнообразных подходов к

программированию отдельных объектов (объектных типов), требуя в общем случае

лишь относительно локальных соглашений о необходимом "взаимопонимании"

передаваемых сообщений.

9. Проблема ответственности.

Основной о-ответ - полная защита от несанкционированного (языком

сообщений) вмешательства в поведение объекта, в результате чего его

создатель получает возможность полностью отвечать за корректность его

поведения. Другими словами, никто не может заставить объект сделать то ( или

сделать с ним то), чего объект не "понимает" и(или) не "контролирует" (ведь

любое сообщение в общем случае анализируется самим объектом).

19.8. Свойства объектной ориентации

1. Новый уровень абстракции.

Объектная ориентация ведет за счет нового уровня абстракции к

обновлению фундаментальных концепций ЯП - управления, развития, защиты,

классификации, модульности, динамизма (высокоразвитой типизацией),

параллелизма (наследуемостью), спецификации, реализации, жизненного цикла

программы (расслоенным программированием и др.) - и в целом к сближению

проблематики ЯП с проблематикой представления знаний и искусственного

интеллекта.

Например, очевидно сходство используемых в объектно-ориентированном

подходе понятия объекта с понятием фрейма, одним из основных в современном

представлении знаний. Понятие объекта можно считать одним из воплощений

(своего рода конкретизаций) понятия фрейма. Стереотипная ситуация - это

объектный тип, слоты - это поля и(или) операции (правила поведения),

играющие вполне определенную роль в рассматриваемой стереотипной ситуации,

конкретная ситуация - это экземпляр объекта.

2. Интеграция понятий и средств информатики.

Объектно-ориентированное программирование знаменует очередной этап

сближения (интеграции) понятий и средств информатики, характерный для нее в

последние годы и проявляющийся не только в названных областях, но и в

создании интегрированных сред (вспомните о назначении ЯП Оберон), в

сближении ЯП и СУБД (экспортное окно - аналог концептуальной схемы в СУБД,

реляционный ЯП близок к языку запросов реляционной БД), ЯП и языков

логического программирования (вспомните о родстве Рефала с Прологом) и др.

3. Целостность ЯП.

Наш анализ в очередной раз демонстрирует, что ЯП - целостная система.

Затронув лишь одно его свойство - развиваемость, мы на основе принципа

концептуальной целостности "вытащили" новый взгляд почти на все аспекты ЯП.

Если бы не уже отмеченный естественный консерватизм языковых ниш, ЯП уже

могли бы стать совершенно иными. Искусство авторов новейших ЯП "объектной"

ориентации проявилось, в частности, в том, что такие ЯП, как Оберон, Турбо

Паскаль 5.5 или Си++ оказались внешне очень похожими на своих более

традиционных предшественников, во всех отношениях плавно вводящими

пользователей в круг совершенно новых идей (в отличие от Симулы-67 и тем

более Смолтока, где к тому же за эти весьма прогрессивные идеи нужно было

платить резким падением эффективности программ. С этим, возможно, в

основном и связан их меньший успех у пользователей, хотя немалую роль

сыграла и неготовность программистской общественности к новой системе

ценностей в программировании, провозглашающей самым дорогим ресурсом труд

квалифицированного человека, а не, например, время работы или память

компьютера.

19.9. Критерий фундаментальности языковых концепций.

Судьба объектной ориентации (от неприятия ее в Симуле-67 до

современного бума) на весьма нетривиальном примере подтверждает один из

основных тезисов нашей книги: почти все фундаментальные концепции

программирования (и современных ЯП) можно объяснить, не привлекая

реализаторской позиции. Другими словами, если необходимо привлекать

реализаторскую позицию, то концепция не фундаментальная. Это, конечно, не

умаляет исключительной значимости применения наилучших алгоритмов и учета

всех возможностей среды для коммерческого успеха программы.

Действительно, никакая проблема реализации не мешала еще двадцать лет

назад изготовить систему, по объектно-ориентированным возможностям

сопоставимую с Турбо Паскалем 5.5 (т.е. включить их, а также соответствующие

модульные средства, еще в первые версии Паскаля). Но само программирование

должно было созреть до понимания фундаментальной значимости удовлетворения

потребности в развиваемости.

20. Заключительные замечания

20.1. Реализаторская позиция

В самом начале книги (п.1.9) мы выделили пять позиций, с которых

намеревались рассмотреть ЯП. До сих пор реализаторской позиции уделялось не

слишком много внимания. Настало время и нам несколько подробнее поговорить о

реализации ЯП.

Безусловно, возможности и требования реализации оказывают существенное

влияние на свойства ЯП. Долгое время это влияние считалось (а в значительной

степени и было) определяющим. С ростом возможностей аппаратуры и методов

трансляции оно ослабевает, уступая технологической позиции. Как уже

сказано, основной методический тезис книги состоит в том, что подавляющее

большинство свойств современных ЯП можно достаточно убедительно объяснить,

не прибегая к реализаторской позиции.

С другой стороны, о реализации ЯП написано много полезных книг (с точки

зрения общих потребностей программистов вполне достаточно книги [37]).

Поэтому постараемся уделить внимание лишь тем аспектам реализаторской

позиции, которые в доступной литературе освещены недостаточно.

Напомним роль реализатора во взаимодействии с представителями остальных

выделенных нами позиций. Реализатор призван обеспечить эксплуатацию ЯП на

всех технологических этапах, опираясь на замысел автора.

[Такое понимание роли реализатора (и реализации) ЯП не стало, к

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

зрения, что задача реализатора - обеспечить ЯП исполнителем (языковым

процессором, транслятором) и только. Именно такая узкая "реализаторская

позиция" (имеющая глубокие корни) - одна из причин положения, при котором мы

вынуждены пользоваться ненадежными трансляторами, колдовать над

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

изменений ЯП, отсутствия сервиса, помогающего создавать и сопровождать

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

т.п.]

Нам не удастся рассмотреть задачу реализатора во всей ее полноте

достаточно подробно. Поэтому поступим так же, как в случае технологической

позиции. Как вы помните, мы кратко рассмотрели жизненный цикл изделия в

целом, а затем выделили только проектирование как представительный этап

цикла. Аналогичным образом дадим общее представление о задаче реализации ЯП

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

Итак, будем считать, что реализация в целом должна обеспечить

эксплуатацию ЯП на всех этапах жизненного цикла комплексного программного

Характеристики

Список файлов книги