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

[shovgenyuk]

Есть класс С1 у которого есть метод М1.
Создаю класс С2 в котором пишу Implements С1.

Как из екземпляра класса С2 вызвать метод М1 ?
На сколько я понимаю, он должен быть унаследован от С1.

[Dmitriy2003]

В VB это не совсем так. т.е. автоматом методы и свойства класса С1 не получиш. однако при использовании IMPLEMENTS имеется возможность унаследовать базовые методы и свойства ручками

[tyomitch]

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

[Dmitriy2003]

Вооплощаем на практике привод потомка к родителю

прошу не ругать за неточность синтаксиса

Public class C1
'
Public sub NachHause(bParam as boolean) as boolean

'
какой нить код здесь
'
end sub
'
end class

Public class M1
IMPLEMENTS c1
'
dim parent as C1
'
public sub NachHause( bParam as boolean) as boolean
parent.NachHause(bParam)
end sub
end class
'
!Лучше плохо отыхать чем хорошо работать, Жуть! да! Но теперьто не все так плохо!
Лично я за VB.

[tyomitch]

Dmitriy2003, ты не в теме.

[GSerg]

tyomitch, тогда покажи наследование с предком и потомком на VB6...

[shovgenyuk]

...
Public class C1
'
Public sub NachHause(bParam as boolean) as boolean

'
какой нить код здесь
'
end sub
'
end class

Public class M1
IMPLEMENTS c1
'
dim parent as C1
'
public sub NachHause( bParam as boolean) as boolean
parent.NachHause(bParam)
end sub
end class
...

Если так писать, то зачем здесь IMPLEMENTS c1 ?
Ето и без IMPLEMENTS c1 работать будет.

Должен быть какой то способ, иначе зачем вообще етот IMPLEMENTS нужен?

[tyomitch]

GSerg, я ведь знаю, что ты понял, что я имел в виду. Чесслово, лень в полтретьего ночи делать пример

[GSerg]

Для реализации интерфейсов. А не для наследования.

[shovgenyuk]

Для реализации интерфейсов. А не для наследования.

В чем это неследования интерфесов, если их все равно нужно по новой переписать, иначе ругается. И даже когда переписать, то имена получаются совсем другие.
Не могу понять зачем нужно такое "наследование", где и как его использовать практически?

[Dmitriy2003]

To: shovgenyuk

может я и не так понял. прошу простить.

но если смотреть дальше то как рас IMPLEMENTS и есть какой никакой выход...

к примеру:
1. Интерфейсный класс I_G1
2 твой класс M1 посредством Implements Реализует I_G1
3 твой класс С1 посредством Implements Реализует I_G1 + реализует М1

далле если какая нить процедура в качестве параметра принимает I_G1 то ты можеш подсунуть ей оба своих класса. Или как раньше переменную типа Object (Что не есть гуд). в этом и есть приемущество сего оператора.

а наследования в VB в чистом виде нету.

[GSerg]

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

А имена "получаются совсем другие" только внутри класса, а не снаружи.

[shovgenyuk]

Выходит что IMPLEMENTS только для того что бы все классы которые созданы, например с IMPLEMENTS С1 имели бы такой же интерфейс как С1. Тоесть что бы показать разработчику что в классе С1 есть такой-то интерфейс, и не только показать, а даже "заставить" разработчика реализовать етот интерфейс, НО в нутри нового класса.
"Наружный интерфейс" нового класса может совсем отличатся от интерфейса класса С1 или если захочет разработчик, то может написать такой же интерфес как в С1.
И какое здесь унифицированное обращение если разработчик может и не реальзовать весь интерфейс в новом классе от наследуемого, но зато разработчик обязательно должен (иначе не компилируется) реализовать етот интерфейс внутри класса, что для унифицированного доступа не имеет никакого значения. Тоесть унифицированный интерфейс зависит не от IMPLEMENTS, а от того перепишет ли его разработчик с наследуемого класса или нет, а IMPLEMENTS только добавит ему лишнюю работу-реализовать интерфейс внутри класса.
Есть еще одна проблема:
Что будет если интерфейс класса С1 будет дополненный (не переписан, а дописан), например каким-то методом? Наверное нужно будет реализовать етот метод во всех классах которые содержат "IMPLEMENTS С1".
Учитывая все ети недостатки не удобнее ли просто сделать шаблон класса С1 и при создании новых классов пользоваться етим шаблоном и не парится с етим IMPLEMENTS?

--------
Простите если я что-то не правильно понимаю, но пока что понимаю я именно так.

[alibek]

В целом понимаешь правильно.
Просто тебе видимо не приходилось писать систему, ориентированную на плугины и расширения. Там Implements очень полезен.

[GSerg]

Выходит что IMPLEMENTS только для того что бы все классы которые созданы, например с IMPLEMENTS С1 имели бы такой же интерфейс как С1.

В том числе и такой же, как у C1 - но C1 не класс, а интерфейс. Интерфейс - описание сигнатур методов, которое не содержит кода.

Тоесть что бы показать разработчику что в классе С1 есть такой-то интерфейс, и не только показать, а даже "заставить" разработчика реализовать етот интерфейс, НО в нутри нового класса.

Именно так. В этом вся идея, вся фишка и вся соль. Только поэтому всё и работает. См. стандарты COM - все методы реализуемого интерфейса обязаны быть реализованы, даже если реализация состоит в выбросе ошибки E_NOTIMPLEMENTED.

"Наружный интерфейс" нового класса может совсем отличатся от интерфейса класса С1

Нет.
У каждого COM-класса может быть сколько угодно внешних интерфейсов. При использовании implements, к списку внешних интерфейсов добавляется ещё один. И он становится исключительно внешним. И никуда разработчик его не денет и не изменит.

или если захочет разработчик, то может написать такой же интерфес как в С1.

Однако в этом случае класс не будет являться реализующим C1 с точки зрения кода. Оператор Is C1 выдаст False. А то, что интерфейс визуально похож с точки зрения человека, не имеет никакого значения.

И какое здесь унифицированное обращение если разработчик может и не реальзовать весь интерфейс в новом классе от наследуемого

В VB6 нет наследования. Никак, ни в какой форме. И реализовать "от наследуемого" ты не можешь.
Если тебя сбивает то, что в твоём C1 присутствует код - так просто убери его оттуда, его там не должно быть, потому что это интерфейс, а не класс.

но зато разработчик обязательно должен (иначе не компилируется) реализовать етот интерфейс внутри класса, что для унифицированного доступа не имеет никакого значения.

Только и именно это имеет значение для цнифицированного доступа. Интефейс реализуется внутри класса, но доступен снаружи. Что, в принципе, очевидно?

Тоесть унифицированный интерфейс зависит не от IMPLEMENTS, а от того перепишет ли его разработчик с наследуемого класса или нет, а IMPLEMENTS только добавит ему лишнюю работу-реализовать интерфейс внутри класса.

Ещё раз: не существует понятия "наследуемый класс" в VB6.
Наследование производится через Ctrl+C, Ctrl+V.

Есть еще одна проблема:
Что будет если интерфейс класса С1 будет дополненный (не переписан, а дописан), например каким-то методом? Наверное нужно будет реализовать етот метод во всех классах которые содержат "IMPLEMENTS С1".

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

Учитывая все ети недостатки не удобнее ли просто сделать шаблон класса С1 и при создании новых классов пользоваться етим шаблоном и не парится с етим IMPLEMENTS?

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

[shovgenyuk]

...Просто тебе видимо не приходилось писать систему, ориентированную на плугины и расширения. Там Implements очень полезен.

Не приходилось, но как раз пришлось
У меня система очень большая, много разных документов и их количество все время увеличивается, почти все ето в одном ехе-файле. Документы пишут разные люди и мне сбрасывают по почте, а я все ето в один проект леплю, при етом возникает очень много разных несовместимостей и проблем. Хочу отделить документы от проекта, что бы кто-то писал документы придерживаясь при етом определенных правил, а я занимался бы организацией взаимодействия етих документов, и что бы каждый документ был физически отделен от главного проекта, например был бы в отдельной dll и к пректу подключался динамически в зависимости от некоторых условий.
Вот и начал я копать в сторону IMPLEMENTS, но кажется мне что нужно как-то по другому, без IMPLEMENTS.

[GSerg]

Нет, нужно именно так.
Но только неясно, что документ делает в dll или в exe.

[shovgenyuk]

Спасибо за пояснения, кое что понял, но не все.

"Наружный интерфейс" нового класса может совсем отличатся от интерфейса класса С1

Нет.
У каждого COM-класса может быть сколько угодно внешних интерфейсов. При использовании implements, к списку внешних интерфейсов добавляется ещё один. И он становится исключительно внешним. И никуда разработчик его не денет и не изменит.

Как мне обратится к етому интерфейсу?
После переменной типа нового класса ставлю точку и никаких интерфейсов от старого интерфейса (наследумого) там не появляется.

но зато разработчик обязательно должен (иначе не компилируется) реализовать етот интерфейс внутри класса, что для унифицированного доступа не имеет никакого значения.

Только и именно это имеет значение для цнифицированного доступа. Интефейс реализуется внутри класса, но доступен снаружи. Что, в принципе, очевидно?

Как он доступен с наружи?

[GSerg]

Как мне обратится к етому интерфейсу?
После переменной типа нового класса ставлю точку и никаких интерфейсов от старого интерфейса (наследумого) там не появляется.

Объяви переменную нужным типом. As C1.

Как он доступен с наружи?

Когда пользователь класса объявит его переменную нужным типом. As C1.

[shovgenyuk]

Но только неясно, что документ делает в dll или в exe.

Документ-это у меня форма(ы) и класс(ы) для записи/редактирования/удаления информации пользователем з/у БД.

[shovgenyuk]

Всем большое спасибо что направляли меня на путь истинный.
Проверил, все работает, теперь все понял

[tyomitch]

Как мне обратится к етому интерфейсу?
После переменной типа нового класса ставлю точку и никаких интерфейсов от старого интерфейса (наследумого) там не появляется.

Объяви переменную нужным типом. As C1.

Как он доступен с наружи?

Когда пользователь класса объявит его переменную нужным типом. As C1.

К слову, именно про это и был мой вчерашний пост в этом топике.
А не про "наследование реализации".

[GSerg]

Вполне допускаю. Но, честно, было непонятно