От ФП к ООП

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

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

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

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

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

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

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

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

ООП на Лиспе

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

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

При организации наследования следует пояснить разницу между моделями обобщенных функций и обмена сообщениями.

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

Но допустим, понадобилось ввести новый класс — раскрашенные круги. Если методы раскраски произвольных фигур уже существовали, то можно унаследовать две особенности:

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

В Лисп есть разные способы размещать коллекции свойств. Один из них — представлять объекты как хэш-таблицы и размещать свойства как входы в нее. В [7] приведен блестящий пример реализации ООП на базе хэш-таблиц. Тогда отдельное свойство можно получать из таблицы в форме:

(gethash 'color obj)

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

(FUNCALLl (gethash 'move obj) obj 10)

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

(DEFUN tell (obj message rest args)
    (APPLY (gethash messmage obj) obj args))

что позволяет сказать объекту, чтобы он переместился на 10 шагов, в форме:

(tell obj 'move 10)

Фактически успех наследования обеспечивает единственная особенность Лиспа: все это работает благодаря реализации рекурсивной версии GETHASH. Таким образом, определение данной функции нам сразу даст все три основные черты ООП.

Посмотрим, во что это обойдется в исходном примере.

Мы должны создать два объекта, один — потомок другого.

В объект "круги" мы помещаем методы для всех кругов. Для начала это функция одного аргумента — объекта, посылающего сообщение:

(SETF (gethash 'area circle-class)
       #' (LAMBDA (x)
          (* pi (expt (rget ' radius x) 2))))

Теперь можно спрашивать о площади круга, она будет вычисляться согласно методу, определенному для класса. Мы используем rget при чтении свойства и tell — при вызове метода.

(rget 'radius our-cicle)
    (tell our-circle 'area)

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

Множественное наследование

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

При реализации такой идеи не следует проверять объект ранее его последователей ( a b c d ):

(d)
        / \   
    (b)    (c) 
        \ /
        (a)

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

Определяемые объекты

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

Функциональный синтаксис

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

Экземпляры

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

Векторная реализация

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

Еще одна реализация

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

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 безымянная копия контекста
 
       (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))
 
    ; значение поля объекта

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

(DEFUN evcon- (c optional a)
    ;                  |_________ключ, объявляющий 
    ;                                   необязательные параметры
       (COND
       ((eval-p (CAR (CAR c)) a) 
        (eval-p (CAR (CDR (CAR c))) a) )
       (T (evcon- (CDR c) a) ) ))
 
    (DEFUN evlis- (m optional a)
       (COND
          ((EQ m NIL) NIL)
          ( T (CONS (eval-p (CAR m) a) 
                    (evlis- (CDR m) a) ) ) ))
 
(DEFUN eval-p (e optional c)
    (COND ((ATOM e) (value e c))
          ((ATOM (CAR e))
           (COND 
 
             ((EQ (CAR e) 'QUOTE) (CAR (CDR e)))
             ((EQ (CAR e) 'COND) (evcon- (CDR e) a))
             ((get (CAR e) 'METHOD) 
             (method (CAR e) (evils (CDR e)) c) )
          (T (apply-p (CAR e)(evlis- (CDR e) c) c))
      ) )
        (T (apply-p (CAR e)(evlis- (CDR e) c) c))
) ) 

(DEFUN apply-p (f args optional c)
    (COND ((ATOM f) (apply-p (function f c) args c))
          ((ATOM (CAR f))
           (COND ((get (CAR f) 'macro)
                  (apply-p (apply-p (get (CAR f) 'macro)
                                    (CDR f) c)
                            args c))
 
                (T(apply-p (eval f c) args c))
           ) )
        (T (apply-p (eval f c) args c))
 ))
 
    (print (eval-p 1))
    (print (eval-p 'a))
    (print (eval-p '(QUOTE b)))
    (print (eval-p '(COND (NIL 6)(T 88) )))
    (print (eval-p '(CAR '(3 2))))

Средства ООП в CLOS на базе стандарта Clisp

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

Классы и экземпляры объектов

(defclass ob () (f1 f2 ...))

Это означает, что каждое вхождение объекта будет иметь поля-слоты f1 f2 ... ( Слот — это поле записи или списка свойств.) Чтобы сделать представителя класса, мы вызываем общую функцию:

(SETF с (make-instance 'ob))

Чтобы задать значение поля, используем специальную функцию:

(SETF (slot-value c) 1223)

До этого значения полей были не определены.

Свойства слотов

Простейшее определение слота — это его имя. Но в общем случае слот может содержать список свойств. Внешне свойства слота специфицируются как ключевые параметры функции. Это позволяет задавать начальные значения. Можно объявить слот совместно используемым.

:allocation :class

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

Суперкласс

Нет необходимости все новые слоты создавать в каждом классе.

Пример: ОО-определение Лисп-компилятора.

;oop-compile
 
    (defclass expr () 
    ((type :accessor td) 
     (sd :accessor ft))
    (:documentation "C-expression"))
 
    (defclass un (expr)
                   ; \_____суперкласс для унарных форм
 
       ((type :accessor td) ;; можно унаследовать,
         (sd :accessor ft)) ;; а здесь не дублировать
    (:documentation "quote car *other *adr"))
 
    (defclass bin (expr) 
       ((type :accessor td) 
         (sd :accessor ft)
         (sdd :accessor sd) )
    (:documentation "cons + lambda let"))
 
    (defclass trio (expr) 
               ;; (bin)  тогда можно не объявлять первые 3 поля
       ((type :accessor td) 
        (sd :accessor ft)
        (sdd :accessor sd)
        (sddd :accessor td) )
    (:documentation "if label"))
 
    (defmethod texrp ((x expr) (nt atom))
       (SETF (slot-value x 'type) nt)
       (SETF (td x) nt) ;;--;; variant
    (:documentation "объявляем тип выражения"))
 
    (defmethod spread ((hd (eql 'QUOTE))
                                  (tl expr))
       (let (  (x (make-instance 'un)) )
          (SETF (ft x) (car tl))
          (SETF (td x) hd)
    ) (:documentation "распаковка выражения"))
 
    (defmethod compl ((hd (eql 'QUOTE))
                                 (tl expr))
          (list 'LDC tl)
     (:documentation "сборка кода"))
 
    (defmethod compl ((hd (eql 'CAR))
                                 (tl expr))  N)
          (append (compl(ft tl) N) '(CAR))
     (:documentation "сборка кода"))
 
    (defmethod spread ((hd (eql 'CONS))
                                  (tl expr))
       (let ( (x (make-instance 'bin)) )
          (SETF (ft x) ( CAR tl))
            (SETF (sd x) ( cadr tl))
            (SETF (td x) hd)
    ) (:documentation "распаковка выражения"))
 
    (defmethod compl ((hd (eql 'CONS))
                                (tl bin) N )
             (append (compl(sd tl) N) (compl(ft tl) N) 
             '(CONS))
     (:documentation "сборка кода"))
    (defmethod compl ((hd (eql '+))
             (tl bin) N )
             (append (compl(ft tl) N) (compl(sd tl) N) 
             '(ADD))
     (:documentation "сборка кода"))
 
    (defmethod spread ((hd (eql 'IF))
             (tl expr))
       (let ( (x (make-instance 'trio)) )
          (SETF (ft x) ( CAR tl))
          (SETF (sd x) ( cadr tl))
          (SETF (td x) ( caddr tl))
          (SETF (td x) hd)
    ) (:documentation "распаковка выражения"))
 
    (defmethod compl ((hd (eql 'IF))
                                (tl expr) N )
       (let ( (then (list (compl(sd tl) N) '(JOIN)))
          (else (list (compl(td tl) N) '(JOIN))) )
          (append (compl(ft tl) N) (list 'SEL then else)
          )
    )(:documentation "сборка кода"))
 
    (defmethod parh ((x expt))
       (let (ftx (ft x))
          (COND
             ((ATOM ftx) (spread 'ADR ftx))
             ((member (CAR ftx) 
              '(QUOTE CAR CONS + IF LAMBDA LABEL LET))
             (spread (CAR ftx) (CDR ftx))
             (T (spread 'OTHER ftx) ))
    )(:documentation "шаг разбора"))
 
    ;====test==========
    (SETF test1 (make-instance 'expr))
    (texpr test1 'expr)
    (SETF (slot-value test1 'sd) (READ))
    ()
 
    (SETF e1 (make-instance 'expr))
    (SETF e2 (make-instance 'expr))

    (SETF e3 (make-instance 'expr))  
       (print (tf e2))
    (SETF (slot-value e3 'type) 'expr)
       (print (tf e3))

    (SETF (slot-value e3 'sd) '(QUOTE const))
 
    (defmethod ep ((x expr))
       ((LAMBDA (xt)
          (SETF (slot-value x 'type) xt) )
        (CAR (slot-value x 'sd)) ) )
    (print (ep e3))
    (print (tf e3))
    (print (td e3))
    (print (sd e3))
 
    (defmethod ep-q ((x (eql 'QUOTE)) (y expr))
    (SETF y (make-instance 'un)))

    (SETF (slot-value y 'type) 'QUOTE)
    (SETF (slot-value y 'sd) y)

    (print (tf (e3 'sd)))
 
    (print (tf e1))
    (print(SETF (slot-value e1 'type) (tf e1)))
    (SETF (slot-value e2 'sd) 'atom1)
    (print (tf (sd e2)))
 
    (print(SETF (slot-value e3 'sd) '(QUOTE const)))
    (print (tf e3))

CLOS, естественно, использует модель обобщенных функций, но мы написали независимую модель, используя более старые представления, тем самым показав, что концептуально ООП — это не более чем перефразировка идей Лиспа. ООП — это одна из вещей, которую Лисп изначально умеет делать. Для функционального стиля программирования в переходе к ООП нет ничего революционного. Такой переход практически не расширяет пространство предстоящих решений. Это просто небольшая конкретизация механизмов перебора ветвей функциональных объектов Императивному стилю ООП компенсирует избыточную целостность представления отлаживаемых программ, смягчает жесткость зависимости компонентов программы от потока информационных процессов.

Более интересный вопрос, что же нам еще может дать функциональный стиль и лисповская традиция реализации систем программирования?

Ответу на этот вопрос посвящены три следующие лекции.