Ув. Guest_333, честно говоря, мне кажется Вы не очень знаете как используется наследование в VB/VBA, потому что в противном случае, Вы бы в MyMethod последнего класса написали бы


(смею предполагать, что в VFP это возможно). Это, конечно, не привело бы к невозможности написания аналогичного функционала на VB/VBA, но, по понятным причинам, увеличило размер кода и потребовало аккуратности при "наследовании интерфейса". Для Вашего же примера, реализация будет такая:

Class1

Class2

Class3

И, наконец, вызов:

Результат:

Вы позволите не приводить код, который требуется при "наследовании интерфейса", для доступа к Property1 из Class3?

Guest_333Если ты этого не сможешь, то дальнейшее обсуждение этого вопроса я считаю бессмысленным. Наследование (пусть даже только наследование интерфейса как в VB), ограниченное всего одним уровнем иерархии, для меня лично серьезным инструментом, который можно было бы использовать в работе, не является
Не хотите - не используйте, можете даже других отговаривать, но качество аргументации и знание предмета должно быть все же повыше.

ASCRUSГоворя про наследование, я имел ввиду впервую очередь наследование форм и визуальных обьектов (насколько я помню, невизуальные классы можно и на VBA катать). Чтобы предупредить вопрос специалистов по Access "А зачем оно нужно, ни разу не пригодилось"
Опять двадцать пять... :)

ASCRUSВ Access, в отличие от PB, к сожалению то же наследование форм не возможно,...
Наследование форм возможно, т.к. каждая форма - это класс, унаследованный от абстрактного класса Form. Далее, к списку радительских свойств, методов и событий можно добавить свои, можно создать своего наследника любой формы и т.д.

ASCRUS...так как в нем форма напрямую завязана с данными, ...
А что имеется в виду под прямой завязкой?

SSYОпаньки... А вот тут, если можно, поподробнее: в Аксесс появилось наследование форм!?
Это то, что ты ниже называешь "теплым" (или наоборот "мягким").

SSYТолько не надо путать теплое с мягким (С). With Events - хорошая "заплатка", но это не наследование, то есть совсем не то, что имел ввиду ASCRUS.
Тогда для непонятливых подробнее объясни, что имел в виду ASCRUS? Что ожидается от наследника формы?
VBA, конечно, не настоящий ОО язык, но "наследование для бедных" ((с) йцук) в нём присутствует.

В качестве примера: я реализовал дерево классов, которое обеспечивает функционал размещения и выравнивания объектов на форме (свойство Align в Delphi и Builder или Dock в .NET), включая сплиттеры, фреймы (панели) и т.п. Там есть базовый класс TControl, который умеет отрисоваться в нужных координатах родителя, установить для себя границы изменения размеров и т.д. И есть его наследники (TFrame, TTabControl, TSplitter и т.д.), которые расширяют функционал базового класса. И есть класс TForm, который обеспечивает всё взаимодействие. Теперь я просто кладу на форму контролы, в tag'ах пишу нужные свойства и форма у меня выравнивается без единой дополнительной строчки кода. Пример можно посмотреть здесь Это, кстати, было сделано в A'97, и поэтому не используется такая фича старших версий, как генерация собственных событий...

Всё вышеизложенное не объявление VBA настоящим объектно-ориентированным языком, а просто пример его возможностей, которые отрицаются в вышестоящих постах.

SSYЯ имел ввиду, что "with events" метод позволяет обрабатывать только то, что уже есть на форме, к которой он "присосался". Ну, например (очень плоский и примитивный), если на все формы надо кинуть дополнительную кнопку, то надо добавлять именно в каждую из них, а не только в предка, от которого наследуются эти формы.
Предок для каждой формы Access - голая абстрактная форма, в которую, действительно, добавить ничего нельзя. Но если ты сделал три разных класса, на основе конкретной формы (например, для реализации различного функционала), то можно добавить кнопку на базовую форму, и она понятно будет работать при создании любого из классов наследников. Но это так, к слову. :)

ASCRUSНу а раз маздайщики сделали его тесную интеграцию с MSSQL, то почему бы спрашивается им нельзя было немножко почесать репу и расширить функциональность Access,
Тогда уже это бы не Access получился, а, например, VB.NET.

Guest_333Нет? Тогда какое же это наследование?
Самое обычное "interface inheritance" - наследование интерфейса.

Guest_333Если я объявлю в Class1 новую переменную Property0 - появится ли она автоматом в Class3? (без_моего_вмешательства_руками в описание классов Class2 и Class3). Нет? Тогда какое же это наследование?
Нет, не появится. Вот с этого и надо было начинать. Я же говорил, тщательнее надо вести дискуссию... Ведь сначала было просто:

Guest_333Чем выпендреживаться чужими цитатами и орать как кастрированному, лучше сделай мне на VB/VBA трехуровневую иерархию наследования с помощью связки "наследование интерфейса + приватный экземпляр родителя" (aka Implements + Dim xxx AS ParentClass)

Ответьте, пожалуйста, я Вам это сделал?
Далее... Вам уже много раз написали, что VBA поддерживает не наследование реализации, а наследование интерфейса. От того, что я буду вынужден написать дополнительный код, с точки зрения внешнего приложения результат не изменится.

Guest_333Ну вот она вся мощь наследования в VB во всей своей красе.
Так, значит наследование все же есть...

Guest_333Использование Tag вместо нормального субклассирования контролов и добавления нужных свойств субклассам. Что Вы будете делать, когда придется еще больше навернуть обработку и придется в контролах еще что-либо набивать на этапе разработки? Какие св-ва базовых текстбоксов использовать? Ведь Tag уже занят!
В Tag'е можно хранить любые другие свойства, они там идут обычным списком. А сам tag был выбран для того, что бы эти свойства прописывать визуально в конструкторе, т.к. наследника контрола на форму не положить, а ручками в коде устанавливать свойства не хочется.

Все остальные рассуждения как бы и не очень по теме. Я не позиционировал Access, как средство замены Delphi, VC, .NET и т.п. поэтому спорить по этому поводу не буду.

Кстати, хотите почитать, что поэтому поводу думает MS?

MSDN - Understanding Interface-based ProgrammingThe Two Faces of Inheritance
Inheritance is an objected-oriented concept that models an "IS A" relationship between two entities. So far, this article has used the term implementation inheritance instead of the more generic term inheritance because extending a super class with a sub class is only one way to leverage an "IS A" relationship. When a class implements an interface, it also takes advantage of an "IS A" relationship. For instance, if a class CBeagle implements the interface IDog, it is correct to say that a beagle "IS A" dog. You can use a CBeagle object in any situation in which an IDog-compatible object is required.

Interface-based programming is founded on a second form of inheritance known as interface inheritance. This means that inheritance does not require the reuse of method implementations. Instead, the only true requirement for inheritance is that a sub class instance be compatible with the base type that is being inherited. The base type that is inherited can be either a class or a user-defined interface. In either situation, you can use the base-type references to communicate with objects of many different types. This allows both forms of inheritance to achieve polymorphism.

Both forms of inheritance offer polymorphism, yet they differ greatly when it comes to their use of encapsulation. Implementation inheritance is based on white-box reuse. It allows a sub class to know intimate details of the classes it extends. This allows a sub class to experience implicit reuse of a super class's method implementation and data properties. Implementation inheritance is far more powerful than interface inheritance in terms of reusing state and behavior. However, this reuse comes with a cost. The loss of encapsulation in white-box reuse limits its scalability in large designs.

As the term black-box reuse suggests, interface inheritance enforces the concepts of encapsulation. Strict adherence to the encapsulation of implementation details within classes allows for more scalable application designs. Interface-based programming solves many of the problems associated with white-box reuse. However, to appreciate this style of programming, you must accept the fact that the benefits are greater than the costs. This is a struggle for many programmers.

When a class implements an interface, it takes on the obligation to provide set methods. Sub class authors must write additional code whenever they decide to implement an interface. When you compare this to implementation inheritance, it seems like much more work. When you inherit from a class most of your work is already done, but when you inherit from an interface your work has just begun. At first glance, implementation inheritance looks and smells like a cheeseburger, while interface inheritance looks like a bowl of steamed broccoli. You have to get beyond the desire to have the cheeseburger to reach a higher level of interface awareness. The key advantage of interface inheritance over implementation inheritance is that it is not vulnerable to the tight coupling that compromises the extensibility of an application.
Про фастфуд прикольно написано...