Все новости от 4 марта 2004 г.

ООП: каким его хотелось бы видеть

Бурное развитие робототехники в этом веке делает весьма актуальной задачу самообучения роботов. Как и во многих компьютерных играх, в них широко используются экспертные системы (ЭС).

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

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

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

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

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

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

Языки высокого уровня (ЯВУ), поддерживающие ООП, называются объектно-ориентированнными. Это С++, Java, SmallTalk, Visual Prolog и множество других. Сейчас как-то не модно не поддерживать в ЯВУ объектно-ориентированность.

Программист описывает сначала некий абстрактный класс объектов, его свойства и программирует методы. Затем из абстрактного класса можно выделить подклассы объектов. У него есть возможность создать в программе объект заданного класса, присвоить ему какие-то свойства и т. д.

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

Добавить новые свойства в описание объекта не так трудно, используя, например, широко применяющийся в Лиспе и Прологе механизм списков. В ряде ЯВУ такая работа со свойствами уже существует. (Нельзя сказать, что ООП не развивается. Недавно в нем появилась парадигма аспектного программирования, см. http://aosd.net/.)

Динамическое создание методов для откомпилированной программы - задача не совсем простая, но, к счастью, сейчас есть такие инструменты, как JIT ("компиляция-на-лету"), динамическая компоновка и др.

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

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

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

В реальных задачах ИИ все распознанные объекты никогда не совпадают, и нам необходима операция типа look like, которой также нет в нынешнем ООП, - определение степени похожести объектов как совпадения их свойств и методов. Вопрос этот весьма не прост и упирается в выбор критериев. Человек определяет похожесть прежде всего по форме и назначению, а затем по другим признакам.

Есть два соображения, почему было бы интересно расширить концепцию ООП. Во-первых, используемая парадигма в значительной степени определяет результат. Например, по мнению Н. П. Брусенцова, создателя троичного компьютера, одной из причин неуспеха японской программы построения машин пятого поколения (www.icot.or.jp/ARCHIVE/HomePage-E.html) было то, что в качестве базового языка для нее был выбран Пролог, базирующийся, если опустить все промежуточные слова о дизъюнктах Хорна, на двоичной логике. А провал Intel с намного опередившим свое время объектно-ориентированным процессором iAPX 432 кроме технологических трудностей, по утверждению Б. А. Бабаяна, обусловлен неправильной работой с объектами, приведшей к резкому снижению производительности.

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

Интересно, что вы думаете по поводу вышесказанного. Пишите мне по адресу: editorial@pcweek.ru.