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

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

Откуда:
Сообщений: 2582

Скажите пожалуйста, как в Access создается класс-наследник?

Откуда:
Сообщений: 2099

в объектной модели VBA нет наследования реализации классов, но есть возможность (множественной) реализации интерфейсов, что даёт возможность создавать «классы, похожие на классы-наследники» (с). Простейший пример здесь.

2 Бенедикт
Надо ли понимать приведенную ссылку так, что Вы настаиваете на том, что этот «простейший пример» правильный в том смысле, что в нем демонстируется поведение, эквивалентное наследованию реализации?

Если речь идет только о наследовании интерфейса , то, конечно, приводимая Вами ссылка дает пример наследования интерфейса. Непонятно — почему этот пример «простейший». «Простейшим» может быть любой (абсолютно произвольно выписанный) пример, демонстрирующий работу Implements.

Откуда:
Сообщений: 2099

Что-то мне не думается, что Вас на самом деле интересует мой ответ на этот вопрос, сколь бы тщательно Вы его не формулировали, но думается, что Вы настойчиво пытаетесь протолкнуть свою мысль, высказанную в прошлой теме, о превосходстве объектной модели Java над остальными (и, следовательно, ошибочности моего примера). Эх, Вы выбрали не того человека для холивара. Я не знаю Java, я не знаю объектной модели Java, её плюсов и минусов, я даже формально не знаю, правильно ли Вы её описали (верю, Вы описали правильно, надеюсь, я понял описание правильно). Мне просто было бы нечего отвечать (а Вам бы было неинтересно), даже если б я с какого-то перепою ввязался. Вы ломитесь в открытую дверь. Я всегда приветствую другую обоснованную точку зрения, и читаю дискуссии самого разного уровня именно потому, что есть шанс увидеть альтернативу, и научиться чему-то новому. Если для решения задачи существуют разные подходы, (мудрый) читатель сам решит: «Ага, мне больше подходит этот», или: «Возьму это отсюда, а то-оттуда». Только вот задача должна решаться одна. Сейчас она не сформулирована, по-прежнему. А на арене два ковёрных — Рыжий Эх и Белый Бенедикт, ага, и кто-то другой с попкорном наблюдает за представлением.

Но это лирика. Поближе к физике.
1) Я считаю, что мой пример эквивалентен, или близок, к следующему коду на C++:
2) Я думаю, что перейти от (условно) моей модели к (условно) Вашей не меняя реализации классов можно: , а наоборот — нет.

«Наследование интерфейса»? Я не говорил о наследовании интерфейса (interface inheritance), но говорил о реализации интерфейса (interface implementation). Я бы мог сказать о наследовании интерфейса, если бы речь шла о другом языке, например MIDL, или о наследовании интерфейсов IUnknown и IDispatch (последний — с оговорками) в классах, используемых в VB/VBA. Приведу цитату из MSDN Library (она про VB.NET, но не думаю, что это существенно в данном случае), отражающую мою позицию:

О «простейшем». Чистая придирка. Пример, IMHO, вписывается в правило Энштейна «делай как можно проще, но не проще чем нужно».

P. S. Дискомфортно — а) «Вы», б) серый ник.

Спасибо за ответ, для меня оказавшийся полезным.
C++ я не владею ни активно, ни пассивно. Поэтому не знал, что то поведение, которое я считал до сих пор нормальным для наследника, в C++ достигается только явным добавлением методу базового класса спецификатора virtual.
Хотя явой я тоже активно не владею (лишь по складам смогу прочесть – что там написано), могу сказать, что там (в яве) все методы по умолчанию виртуальные. Более того, методы, заявленные как не виртуальные, не могут быть перекрыты синтаксически. ( не знаю – существуют ли для этого какие-либо интроспективные трюки). Таким образом, описываемое тобой поведение там (в яве) синтаксически невозможно. При приведении объекта к переменной супертипа будет вызван метод, переопределенный в наследнике. Если же оказалось, что этот метод работает именно так, как определено в базовом классе, то это означает одно из двух – метод базового класса виртуальный и не был переопределен в классе-наследнике, либо метод базового класса явно заказан как final и в наследниках его определения не может быть.

Ты ошибаешься, обвиняя меня в проталкивании чьих-то преимуществ. Это был единственный известный мне вариант взаимоотношений между классами и суперклассами.

Если разработчики решили C++ решили по умолчанию предоставить иную альтернативу, а ту, которая мне представлялась естественной, создали как требующую явного объявления – значит это кому-то нужно.

Я легко представляю себе практическую полезность утилитарного кода, выполняющего массовые операции над наборами объектов путем вызова виртуального метода базового класса так, что выполняется код, специфичный для класса который представляет этот экземпляр.
Совместить практическую полезность переопределения метода в наследнике с вызовом на переменной базового класса метода, реализованного в базовом классе после прямого приведения экземпляра объекта к супертипу, я пока не могу.
Такая логика (за отсутствием вменяемых примеров) мне все еще представляется вывернутой наизнанку.
Понятно, что если наследовать класс «печатать на принтере» от класса «рисовать на дисплее», то в результате приведения потомка к предку и вызова метода «рисовать», появляется желание увидеть что-то на экране, а не услышать шуршание бумаги.
Такая цепочка наследования вызывает сомнение. А построить логичную, в которой именно такое поведение требуется, я сам не могу.
Как минимум — хорошо, что C++ предоставляет возможность поведения по вызоввам перекрытых методов на переменных суперклассов, эквивалентное привычному для меня.

Откуда: Харьков
Сообщений: 817

. эх
Если Вас действительно интересует эта тема, есть хорошая книга «Крепкий орешек Visual Basic. Издание второе» Автор Мак-Кинни Брюс, из команды создателей VB5. Там отличная глава 3 Объектный путь Бейсика.

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

Другие статьи:  Договор об организации перевозки заявка

Если я правильно понял в чем вопрос то вот Вам пример из этой книги

Предположим есть класс CMotivate содержащий кроме прочего

Предположим он уже в работе (в другом Вашем компоненте или у Заказчика), но возникла необходимость расширить его функциональность, не переписывая компоненты использующие его.
«Не имея ни малейшего желания переписывать весь класс заново, Вы повторно используете в CMotivate2 существующую часть класса и вводите новые возможности за счет делегирования:»

«Класс CMotivate2 делает тоже что и класс CMotivate, плюс что то ещё, но не работает в том же контексте». Потому что если где то существовала функция:

То будет ошибка при:

Тогда мы создаем CMotivate3, который д.б. полиморфным с классом CMotivate

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

«Реализуя метод CMotivate_Cheer за счет делегирования, класс CMotivate3 предоставляет клиентам CMotivate расширенную версию метода Cheer. Для клиентов CMotivate3 приходится создавать отдельный открытыметод Cheer, но тот может спихнуть (делегировать) свою работу методу CMotivate_Cheer»

В целом я не очень понял (точно — совсем не понял), что именно вы пытались пояснить.
Расширение функционала компонентов не требует наследования, реализованного
«по Бенедикту и умолчаниям в C++» .

Защишенные элементы в VB6 есть. И скрытые и дружественные.

Касательно наследования реализации против наследования/реализации интерфейсов.

Для меня второе — вещь безусловно полезная. Создание т.н. «гибких» систем почти на 100% состоит в реализации грамотно построенных интерфейсов. В практичесокй пользе наследования реализации (любого из двух прозвучавших родов, при том, что о втором я даже не подозревал)
мне пока не удалось убедиться. Пока у меня впечатление, что наследование реализации имеет тенденцию создает больше головной боли — жесткую, с трудом управляемую структуру зависимого кода, не подлежащего рефакторингу в практически значимых случаях.

Мне ни разу всерьез не пришлось жалеть о нехватке наследования в VB/VBA

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

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

Откуда: Санкт-Петербург
Сообщений: 235

Откуда:
Сообщений: 12338

Откуда: Санкт-Петербург
Сообщений: 235

Откуда:
Сообщений: 6666

Откуда: Moscow
Сообщений: 1178

В Офисе 2000 появилась такая возможность. Для этого необходимо воспользоваться ключевым словом Implements.

Подробнее про Implements смотри в справке.

Откуда: Санкт-Петербург
Сообщений: 235

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

Откуда: Пенза
Сообщений: 2574

Среда VBA хотя и позволяет создавать собственные классы и их экземпляры, но практическая ценность от этого невелика. В объектно-ориентированной модели VBA отсутствует ее важнейший компонент — принцип наследования. Он заменен так называемым «встраиванием».

Тем не менее, в классах VBA можно определять properties, поля и методы, создавать экземпляры классов и т.п.

Пример объявления класса (Insert -> Class Module):

Пример создания экземпляра и его использования:

Откуда:
Сообщений: 62

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

Работаю в Excel 2010

Откуда: Краснодар
Сообщений: 1289

в VBA нет понятия такого «статичный класс» или «статичный метод». Метод можете поместить в стандартный Модуль, обращаться также mySub или MyModuleName.mySub

Откуда:
Сообщений: 62

не соблаговолит ли уважаемый джин VSVLAD открыть приложенный файл, проверить, работает ли у него процедура Test, и, если да, то объяснить, почему?

К сообщению приложен файл (PredeclaredClass.xls — 39Kb) cкачать

Откуда: Зеленоград, Москва, Россия
Сообщений: 18248

должна. Её хорошо об этом попросили. Только не очень хорошо видно, как. Где объявление объектной переменной, её инициализация?

Откуда: Краснодар
Сообщений: 1289

Хорошо, предположим что аттрибут PublicNotCreatable сотворил чудо, и не создавая экземпляра мы присвоили значение в свойство. Но если посмотреть поближе, то можно увидеть что разрешено создавать экземпляры класса и присваивать в эти свойства.

Компилятор VB.NET нарисует ошибку на подобный код (свойство value объявить shared), так как нельзя статичному полю через объект-экземпляр класса. А если поле не статичное, то мы не сможем к нему обратиться. Итого, то что VBA хитрит и даёт доступ к методам/свойству — не говорит о том что методы и свойства статичные.

Откуда: Зеленоград, Москва, Россия
Сообщений: 18248

Это не VB. Тут существует «объект по умолчанию». Или, если хотите, объект-прототип, от которого порождаются объекты этого типа, если объявлены в коде.

К сообщению приложен файл (PredeclaredClass.xls — 31Kb) cкачать

Откуда:
Сообщений: 1258

У-у-у, шайтан

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

Проясните, пожалуйста, кто может, ситуацию с реализацией интерфесов в VBA. Я, видимо, саму идею не очень догоняю.

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

Я создаю класс BasicClass, в нем:

public function ShowInfo () As String
end function

Далее создаю класс MyClass и в нем пишу: implements BasicClass

В результате я действительно должен реализовывать в классе MyClass метод ShowInfo()

public function BasicClass_ShowInfo() As String
BasicClass_ShowInfo = «инфа»
end function

но почему это так жутко выглядит? при вызове метода я должен делать так:

Dim result AS String
Dim obj AS New MyClass
result = MyClass.BasicClass_ShowInfo()

такая кривизна наводит меня на мысль что я что-то делаю или понимаю не так. в чем тут вообще суть? ;))) Зачем VBA приделывает «BasicClass_» к методам «наследуемого» (или как это вообще называется?) класса?

Другие статьи:  Социальные пособия пенсионерам по возрасту

может я вообще не должен методы показывать пользователям, а только свойства?

В результате я действительно должен реализовывать в классе MyClass метод ShowInfo()

public function BasicClass_ShowInfo() As String
BasicClass_ShowInfo = «инфа»
end function

нет.
Функции, реализующие методы BasicClass в MyClass должны объявляться как Private.

Вы не должны выписывать интерфейсы таких функций вручную.
Для реализации таких функций в MyClass:
Выберите в левом поле со списком редактора VBA – списке объектов BasicClass
В правом поле со списком окна редактора (списке процедур/событий) появится список обязательных к реализации функций BasicClass. При выборе любого из них интерфейс функции будет вписан в текст текущего модуля класса. Вам останется только наполнить тело функции фактической реализацией.

но почему это так жутко выглядит? при вызове метода я должен делать так:

Dim result AS String
Dim obj AS New MyClass
result = MyClass.BasicClass_ShowInfo()

Ваша запись вообще дважды ошибочна, но я не буду останавливаться на этом

По существу вопроса.
Основное назначение множественности интерфейсов – обеспечить создание специализированного на выполнении определенных функций кода, который мог бы повторно использоваться с экземплярами различных классов. Например, в обычном модуле Вы можете написать функцию вида
Такую функцию Вы сможете использовать с любым классом MyClass, MyClass2, …, MyClass1024
Который реализует (Implements) интерфейс класса BasicClass

Напрямую на экземпляре MyClass воспользоваться ShowInfo нельзя (если только Вы не написали одноименного метода в MyClass). Вы должны использовать явное приведение типов.
Часто пишут так.

Из-за размножения переменных программистами на VB|VBA такая запись обычно признается неудачной.
(код, использующий свойства MyClass начинает «требовать» явного определения переменных для реализуемых классом интерфейсов).
Как workaround для такой ситуации советуют завести функцию приведения в обычном модуле
Тогда приведенный код может быть переписан так

Иногда признается уместным и приемлемым размещение в MyClass метода, возвращающего экземпляр интерфейса BasicClass.
В MyClass пишут :
Тогда код, использующий MyClass и прямо реализуемый им иной интерфейс
Может быть переписан так

Зачем VBA приделывает «BasicClass_» к методам «наследуемого» (или как это вообще называется?) класса?

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

2 k!rill
Посмотрите на количество слов, которое потребовалось для краткого ответа.
лучше Вам сначала почитать что-нибудь про VB|VBA программирование.
Старайтесь задавать вопросы не на понимание , а на примеры практического использования
«я не понимаю» — это Ваша проблема.

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

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

Хотел бы услышать ваше мнение насчет применения ООП в VBA.

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

Dim x As New nerv ‘ имя класса — мой ник : )
Dim col As New Collection

‘ пример использования — формирование строки из коллекции
MsgBox nerv.Collection.toString(col)

‘ формирование массива из коллекции
arr = nerv.Collection.toArray(col)

Я уж молчу про то, что нельзя сделать просто и очевидно — добавить свои методы/свойства к предопределенным объектам:
MsgBox col.toString()
arr = col.toArray()

но, вам не кажется, что добавлять модуль класса, просто для того, чтобы там написать Public Collection As New Collection_ — лишним?

Это только верхушка айсберга: почему приватные поля класса видны при создании объекта в отладчике? Они ж приватные! При обращении к ним возникает ошибка. Дядя, Бил, ты перемудрил.

Чебурашка стал символом олимпийских игр. А чего достиг ты?
Тишина — самый громкий звук

По-моему, синтаксис должен быть нескольлько другой:

Dim x As New nerv ‘ имя класса — мой ник : )
Dim col As New Collection

‘ пример использования — формирование строки из коллекции
MsgBox x.CollectionToString(col) ‘CollectionToString — название метода

‘ формирование массива из коллекции
arr = x.CollectionToArray(col) ‘CollectionToArray — название метода

> но, вам не кажется, что добавлять модуль класса, просто для того, чтобы там написать Public Collection As New Collection_ — лишним?

А зачем это делать? Коллекция объявлена и заполняется в обычном модуле, потом передается как аргумент методу класса nerv, который ее обрабатывает.

> Я уж молчу про то, что нельзя сделать просто и очевидно — добавить свои методы/свойства к предопределенным объектам

В VBA есть механизм наследования — с помощью оператора Implements. Я никогда его не использовал, но, наверно, можно создать класс NervCollection, который унаследует свойства и методы коллекции и добавит свои. Попробуй 🙂

> почему приватные поля класса видны при создании объекта в отладчике?

Что ты имеешь в виду? Вот я написал в модуле класса Class1

Public x
Private y

Public Sub pubs()
End Sub

Private Sub pris()
End Sub

Теперь пишу в процедуре обычного модуля:

Dim a As Class1
a.

После ввода точки выпадает только «x» и «pubs».

ура, Казанский ответил! : )

>По-моему, синтаксис должен быть нескольлько другой:
>MsgBox x.CollectionToString(col) ‘CollectionToString — название метода
Логику понял, но это не совсем то, что я хотел, т.к. кроме коллекции, планирую еще другие доп. функции насувать ) Т.е. мой ник как namespace (пространство имен), которое «подразделяется» на подструктуры, а-ля дерево каталогов.

>В VBA есть механизм наследования — с помощью оператора Implements. Я никогда его не использовал, но, наверно, можно создать класс NervCollection, который унаследует свойства и методы коллекции и добавит свои. Попробуй 🙂
можно пример?

Другие статьи:  Приказ министра обороны российской федерации 255 от 23042019 г

>А зачем это делать? Коллекция объявлена и заполняется в обычном модуле, потом передается как аргумент методу класса nerv, который ее обрабатывает.
если честна, хотел бы этого избежать, т.е. вызывать методы напрямую — коллекция.метод, т.е. способ collection.toString() — предпочтительный

>После ввода точки выпадает только «x» и «pubs».
в окне локалс

Чебурашка стал символом олимпийских игр. А чего достиг ты?
Тишина — самый громкий звук

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

Ключевые слова: Implements, VBA

Описывается редко используемый (за исключением реализации интерфейсов при создании COM-обьектов) Implements.

Visual Basic 6.0 does not support implementation inheritance.

In interface inheritance in Visual Basic 6.0, any class can act as an interface base class. There is no syntax for preventing any class to act as an interface base class. Likewise, there is no syntax to demand that a class act only as an interface base class.

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

Есть общераспространенное мнение, что «объектность» в 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

— чем это не «наследование»?

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

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

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

Мистик [досье] , да, ссылки могут получаться длинными . но зато — в них будет отражена СТРУКТУРА объекта.
Опять же — есть ведь конструкция «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] Королев [досье] при создании нового объекта в памяти возникает НОВЫЙ ЭКЗЕМПЛЯР всей его «функциональности», — независимо от того — агрегация это или «настоящее» наследование.

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

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

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

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

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

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

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

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