Объектно-ориентированное программирование

Удобный подход к организации программ "отдельная работа отдельно программируется и отдельно выполняется" успешно показал себя при развитии операционной системы UNIX как работоспособный принцип декомпозиции программ. Но существуют задачи, например реализация систем программирования, в которых прямое следование такому принципу может противоречить требованиям к производительности. Возможен компромисс "отдельная работа программируется отдельно, а выполняется взаимосвязано с другими работами" [ [ 67 ] ], что требует совмещения декомпозиции программ с методами сборки - комплексации или интеграции программ из компонентов. Рассматривая комплексацию как еще одну "отдельную" работу, описываемую, например, в терминах управления процессами, можно констатировать, что эта работа больше сказывается на требованиях к уровню квалификации программиста, чем на объеме программирования. При достаточно объективной типизации данных и процессов, возникающих при декомпозиции и сборке программ определенного класса, строят библиотеки типовых компонентов и разрабатывают компонентные технологии разработки программных продуктов - Corba, COM/DCOM, UML и т.п.. Одна из проблем применения таких компонентов - их обширность [ [ 76 ] , [ 86 ] ].

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

Механизмы ООП обеспечивают наследование свойств по иерархии классов объектов и так называемый "дружественный" доступ к произвольным классам. Расширение программ при объектно-ориентированном подходе к программированию выглядит как простое дописывание новых определений. Библиотеки типов данных и методов их обработки легко вписываются в более общие системы. Спецификация интерфейсов в принципе может быть сопровождена верификацией реализации компонент. Возможна факторизация программ на компоненты и рефакторизация программных компонент в стиле экстремального программирования [ [ 12 ] , [ 46 ] ].

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

• уменьшение трудоемкости последующих шагов,
• отладку прототипов сложных компонентов,
• подготовку демонстрационного материала.

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

Дальнейшие шаги раскрутки можно упорядочить по актуальности реализации компонентов, обеспечивающих положительную оценку системы пользователем. Это позволяет развить представление о принципах декомпозиции программ более созвучно ООП: "отдельная работа обнаруживается независимо от остальных работ". Наиболее устойчивая и значимая классификация работ по реализации системы программирования может быть установлена как обеспечение механизмов надежного функционирования информационных систем - "отдельная работа - это отдельное средство повышения надежности программирования". Ряд таких средств можно выделить в любом языке программирования: вычисления, статическое и динамическое управление процессами, логика выбора хода обработки информации, дисциплина именования памяти и доступа к расположенным в ней данным, правила укрупненных воздействий на блоки данных и иерархию процессов, диагностика и обработка событий - перечень открытый [ [ 33 ] ].

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

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

(defun classes (cl) (cond 
               (cl (cons (cdar cl) (classes (cdr cl)))) ))

; вывод формулы классов аргументов из определения параметров метода
; Nil - произвольный класс

(defun argum (cl) (cond 
             (cl (cons (caar cl) (argum (cdr cl)))) ))

; вывод списка имен аргументов из определения параметров метода

(defun defmet (FMN c-as expr)
              (setf (get FMN 'category) 'METHOD)
              (setq ML (cons(cons(cons FMN (classes c-as))
                                  (list 'lambda (argum c-as) expr) ) ML))
       FMN )

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

(defun defcl (NCL SCL FCL ) ; имя, суперкласс и поля/слоты класса
             (setq ALLCL (cons NCL ALLCL))
             (set NCL (append FCL SCL))  )

; значением класса является список его полей, возможно, со значениями

(defun ev-cl (vargs) (cond 

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

          (vargs (cons (cond 
                           ((member (caar vargs) ALLCL) (caar vargs))  )
                       (ev-cl (cdr vargs))))  ))
; Nil если не класс

(defun m-assoc (pm meli) (cond (meli (cond ((equal (caar meli) pm)(cdar meli))
                           (T(m-assoc pm (cdr meli)))))))

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

(defun method (MN args &optional c) 
      (apply (m-assoc (cons mn (ev-cl args)) ML)
                args c))

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

(defun instance (class &optional cp) (cond

; подобно Let безымянная копия контекста

                (class (cond ((atom (car class))(instance (cdr class) cp))
                             ((assoc (caar class) cp) (instance (cdr class) cp))
                             (T(instance (cdr class) (cons (car class) cp))) 
))     )  cp)

(defun slot (obj fld) (assoc fld obj))

; значение поля объекта

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

Показанный в [ [ 72 ] ] аналогичный пример работает по первому аргументу (выбор подходящего метода рассчитан на то, что достаточно разобраться с одним аргументом). Система CLOS (GNU Clisp) делает это на всех аргументах, причем с рядом вспомогательных средств, обеспечивающих гибкий перебор методов и анализ классов объектов [ [ 82 ] ].

Рассмотрим отличия в базовых понятиях и методах работы с ними: