Xpoint
   [напомнить пароль]

наследование в VBA

Метки: [без меток]
[удл]
2004-06-02 11:32:36 [обр] Иван FXS[досье]

Есть общераспространенное мнение, что "объектность" в VBA - неполноценная, не соответствует "стандарту ООП" (кстати, а существует ли он - "стандарт ООП"? Если да - дайте ссылочку, плз!) ...
Вот, например, наследование ... вроде бы в VB его нет ... однако, пусть есть два класса:

'=== parent_cls: ===
public parent_class_property as String

и

'=== child_cls: ===
public p as New parent_cls

- видно, что у объекта класса child_cls присутствуют все свойства parent_cls:

'=== child_cls: ===
 dim my_object as New child_cls
with my_object
                .p.parent_class_property = "записал"
   MsgBox .p.parent_class_property + " - прочитал"
End with

- чем это не "наследование"?

спустя 49 минут [обр] Мистик(7/13)[досье]

То, что вы предлагаете, называется агрегация.

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

Имхо, граница между концепциями ООП достаточно условна, и тяжело вычленить какой-либо принцип в отдельном виде. Наследование это не только все поля предка. С наследованием тесно связана возможность переопределения поведения предка (посредством перекрытия виртуальных функций (C++) или обработки сообщений (Smalltalk)).

спустя 1 час [обр] Кирилл [Kirk] Королев(3/673)[досье]
Очень просто. При нормально реализованном наследовании в памяти есть только экземпляр объекта Child, при этом доступны все свойства/методы и его, и родителя. В данном случае - два экземпляра разных классов. Более того, при разрушении "дочернего" объекта, если в Class_terminate явно нет вызова разрушения "родителя" - этот экземпляр останется жить.
спустя 1 час 23 минуты [обр] Иван FXS[досье]

Мистик[досье], да, ссылки могут получаться длинными ... но зато - в них будет отражена СТРУКТУРА объекта.
Опять же - есть ведь конструкция "With".
Кроме того, эту структуру можно ведь и "скрывать":

'=== "самоссылающийся" класс Parent__cls ===
Public p As New Parent__cls
Public s As String

Private ppp_pvt As New Parent__cls

Public Function ppp() As Parent__cls
Set ppp = Me.p.p.p
End Function

'=== проверка работы ===
Sub p___TEST()
 Dim p_Object As New Parent__cls
With p_Object
    .p.p.p.s = ".p.p.p.s"
    MsgBox .ppp.s
    Stop
End With
End Sub

Кирилл [Kirk] Королев[досье] при создании нового объекта в памяти возникает НОВЫЙ ЭКЗЕМПЛЯР всей его "функциональности", - независимо от того - агрегация это или "настоящее" наследование.

спустя 3 минуты [обр] Иван FXS[досье]
Сорри, строка "Private ppp_pvt As New Parent__cls" - лишняя ...
спустя 2 часа 34 минуты [обр] Кирилл [Kirk] Королев(3/673)[досье]
при создании нового объекта в памяти возникает НОВЫЙ ЭКЗЕМПЛЯР всей его "функциональности"
Иван FXS[досье] Нет "экземпляра функциональности", есть экземпляры объекта/класса. В вашем примере порождается ДВА экземпляра.
спустя 31 минуту [обр] Иван FXS[досье]
Да, два объекта. Но у них ведь РАЗНАЯ "функциональность" и только ВМЕСТЕ они "предоставляют" тот же набор "функциональности", который в "правильном" ООП содержался бы в ЕДИНОМ объекте-с-наследованием ...
спустя 11 минут [обр] Кирилл [Kirk] Королев(3/673)[досье]
Иван FXS[досье] это ответ на вопрос "чем это не наследование".
В ВБ реализован только один базовый принцип ООП - инкапсуляция. Поскольку нет наследования, то и полиморфизма, натурально, быть не может.
спустя 1 час 8 минут [обр] Иван FXS[досье]

Не вижу я ответа :-(
Я утверждаю, что наследование (в интерперетации, например, http://www.i2r.ru/static/374/out_15748.shtml) - ПО СУТИ вполне реализуемо в VB: мы пишем сначала некий "универсальный" класс, а потом - несколько различных "производных" классов, для объектов каждого из которых ТРИВИАЛЬНЫМ ОБРАЗОМ доступны все методы и свойства "универсального" класса: в синтаксесе child.p.parent_property . Ведь добавочка ".p." - это не более чем синтаксис!

Что касается полиморфизма: если у нас в "родительском" классе есть, например, метод abs(), то в "производных" классах мы можем либо использовать его - в синтаксесе child.p.abs(), либо - создать собственный метод abs() и использовать его - в синтаксисе child.abs() ...

А поскольку о наличии инкапсуляции мы уже согласны, то получается, что все три "кита" ООП - реализуемы в VBA ...

спустя 43 минуты [обр] Сергей Круглов(19/2057)[досье]
В том-то и фигня, что мы, получается, заботимся о наследовании и полиморфизме сами, а оно должно происходить само. Мы вообще не должны думать, на каком уровне иерархии определен тот или иной метод или поле. Может, у меня из класса A выведен B, из B - C, из C - D. И как прикажете мне обращаться в D к свойству, определенному последний раз в A или B?
C.B.A.width?
Застрелицца про войну...
  1. s. В конце-концов, так можно дойти до того, что ООП в полнм объеме есть в ассемблере. Ведь все ж в принципе можно "тривиальным образом" ручками организовать...
спустя 29 минут [обр] Мистик(7/13)[досье]
Иван FXS[досье]
По поводу структуры. Структура объекта подверджена изменениям. Соответственно будет меняться код, основаный на структуре. Нужно за этим следить. Неприятно.
спустя 35 минут [обр] Кирилл [Kirk] Королев(3/673)[досье]
Что касается полиморфизма: если у нас в "родительском" классе есть, например, метод abs(), то в "производных" классах мы можем либо использовать его - в синтаксесе child.p.abs(), либо - создать собственный метод abs() и использовать его - в синтаксисе child.abs()
Ну и представьте себе, сколько нужно будет всего написать, ежели понадобится добавить один метод к суперклассу, у которого иерархия в пяток уровней. Про деструкторы я уже говорил. Удачи, в общем.
спустя 20 часов [обр] Даниэль Алиевский(1/125)[досье]

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

Чтобы понять, есть ООП или нет, по-моему, надо проверить: можно ли создать класс (не законченное приложение, а именно модуль, библиотеку), которым смогут впоследствии пользоваться другие разработчики и который будет удовлетворять "трем китам".

ООП позволяет создать класс, у которого поведение методов заранее не фиксировано - в тот момент, когда модуль создается и предлагается, допустим, в продажу. Программист, который воспользовался модулем, В ПРИНЦИПЕ не может узнать о классе ничего, кроме набора public-членов. Наследники этого класса для него неразличимы, хотя вести себя могут несколько по-разному.

Чуть конкретнее (пример шаблона Factory). Допустим, есть абстрактный класс Service с закрытым конструктором и статическим методом getInstance, возвращающим экземпляр. У этого экземпляра есть документированные методы - например, это дисковый сервис. Но реально getInstance возвращает экземпляр не Service, а его наследника - внутреннего закрытого класса, соответствующего текущей операционной системе. Программа, использующая Service, ничего не знает - и не может знать - об этих наследниках. Соответственно, автору класса Service ничто не мешает подключать обслуживание все новых операционных систем, не затрагивая уже написанных (и скомпилированных) программ, использующих Service. Язык ГАРАНТИРУЕТ, что если вы написали класс правильно, то его можно будет менять в определенных пределах с сохранением совместимости. Полиморфизм + инкапсуляция.

На JavaScript, скажем, такое ООП реализовать можно, хотя и несколько неуклюже. (И с некоторыми оговорками: скажем, надо запретить программам-клиентам изучать исходный текст методов объекта. Но похожие оговорки будут и на C++: программы-клиенты не должны анализировать память на низком уровне. Вот в Java можно и без оговорок.) На ассемблере - очевидно, нельзя. Даже если промоделировать виртуальные методы таблицей адресов, никто не может заставить пользователя, к примеру, не анализировать структуру этой таблицы. Что имеет место на VBА?

Powered by POEM™ Engine Copyright © 2002-2005