Кто нибудь копал на тему реализации в компиляторе (умеренного) множественного наследования?
Это одна из вещей которых мне иногда не хватает, с копи пастом некрасиво получается, да и править неудобно.
Множественное наследование
Модератор: Модераторы
множественное наследование ж признано злом? Тем более в objfpc все классы от TObject наследуются, тогда нужно и виртуальное наследование придумывать.
есть интерфейсы - их и нужно использовать, заодно не будет потом мучительно больно приспосабливаться к java, C#, delphi, perl, php5+, python и другим современным ООП ЯП.
как говорят классики - если вам нужно множественное наследование, то у вас что-то не то с дизайном.
есть интерфейсы - их и нужно использовать, заодно не будет потом мучительно больно приспосабливаться к java, C#, delphi, perl, php5+, python и другим современным ООП ЯП.
как говорят классики - если вам нужно множественное наследование, то у вас что-то не то с дизайном.
sts писал(а):Кто нибудь копал на тему реализации в компиляторе (умеренного) множественного наследования?
Это одна из вещей которых мне иногда не хватает, с копи пастом некрасиво получается, да и править неудобно.
А чем плоха агрегация? или делегирование еще например.
fpc поддерживает делегирование? делегирование, насколько помню частный случай множественного наследования, по сути то что чаще нужно.
агрегация несколько криво, например есть TForm1 и TTreeNode (как пример степени различия классов) нужно добавить методысвойства получения прав доступа к этим объектам, создаем класс TAccessRight с кучкой методов по получению прав, заводим у TForm1 и TTreeNode - FAccessRight: TAccessRight, объявляем пропертю AccessRight, в Create Destroy создаемудаляем FAccessRight, далее в процессе использование пишем Form1.AccessRight.getAccessRight(...)
и это вместо того чтоб написать TForm1 = class(TForm, TAccessRight) а в коде Form1.getAccessRight(...)
Добавлено спустя 2 минуты 59 секунд:
интерфейсы мало того что тормознее, так еще больше порождают копипаста и соответственно еще более желательно мнж. наследование
Добавлено спустя 7 минут 34 секунды:
классики просто теоретики а на практике ты имеешь уже предопределенную иерархию классов в которую не можешь вмешаться, грубо говоря, добавить в TPersistent метод getAccessRight (хотя в fpc laz это можно но не приветствуется)
агрегация несколько криво, например есть TForm1 и TTreeNode (как пример степени различия классов) нужно добавить методысвойства получения прав доступа к этим объектам, создаем класс TAccessRight с кучкой методов по получению прав, заводим у TForm1 и TTreeNode - FAccessRight: TAccessRight, объявляем пропертю AccessRight, в Create Destroy создаемудаляем FAccessRight, далее в процессе использование пишем Form1.AccessRight.getAccessRight(...)
и это вместо того чтоб написать TForm1 = class(TForm, TAccessRight) а в коде Form1.getAccessRight(...)
Добавлено спустя 2 минуты 59 секунд:
интерфейсы мало того что тормознее, так еще больше порождают копипаста и соответственно еще более желательно мнж. наследование
Добавлено спустя 7 минут 34 секунды:
как говорят классики - если вам нужно множественное наследование, то у вас что-то не то с дизайном.
классики просто теоретики а на практике ты имеешь уже предопределенную иерархию классов в которую не можешь вмешаться, грубо говоря, добавить в TPersistent метод getAccessRight (хотя в fpc laz это можно но не приветствуется)
sts писал(а):классики просто теоретики а на практике ты имеешь уже предопределенную иерархию классов в которую не можешь вмешаться, грубо говоря, добавить в TPersistent метод getAccessRight (хотя в fpc laz это можно но не приветствуется)
Были бы хелперы как в дельфи...
хелперы тоже нужны, к томуже в реализации это значительно проще (которые как в делфи) так как добаляют только методы, а если еще и поля добавлять вообще былобы отлично и нетак сложно как с мнж наследованием
Добавлено спустя 2 часа 48 минут 41 секунду:
Все читаете и читаете (тему), нет бы написали чего нибудь...
Самое забавное что в fpc уже есть все необходимые механизмы для реализации (ограниченного) мнж наследования, например, решим выше указанную задачу через интерфейсы:
объявляем интерфейс IAccessRight с методом getAccessRight(...) далее делаем
TForm1 = class(TForm, IAccessRight) и реализуем его (интерфейс) через FAccessRight класс TAccessRight (1) так как getAccessRight(...) сложен и в нем используется кучка приватных методов, ну или тупо реализуем их в TForm1(2) а в TTreeNode1 копипастим.
Недостатоки первого варианта: нельзя (при Form1: TForm1) написать Form1.getAccessRight(...) а можно либо Form1.FAccessRight.getAccessRight(...) либо (Form1 as IAccessRight).getAccessRight(...) оба выглядят криво, также если нужны разные реализации getAccessRight(...) надо придумывать механизмы чтоб TAccessRight это учитывал.
Во втором вызовы прямые но копипаст все портит, при изменении интерфейса много править.
А теперь представим следующую реализацию мнж наследования, объявляем:
TAccessRight = class и TForm1 = class(TForm, TAccessRight), компилятор смотрит — оба-на в TForm1 вторым указан класс TAccessRight, он автоматом объявляет интерфейс с тем-же именем и копирует реализацию из TAccessRight в TForm1 в итоге вместо TForm1 = class(TForm, TAccessRight) получаем TForm1 = class(TForm, TAccessRight-интерфейс) плюс поля и методы (которые вставляется перед собственными TForm1), более того методы из TAccessRight (технически) можно оверрайдить. Получаем как раз второй вариант решения, но гораздо меньше писать кода и т.д.
Оператор AS немного надо будет переделать, т.е., при (Form1 as TAccessRight) хоть и известно что TAccessRight класс но если в предках его не найдено то надо поискать в таблице интерфейсов с тем-же именем (IS аналогично)
И все нормально, в рамках текущих структур данных (VMT и т.д.)
Так что тезис - мнж наследование — зло - это от неграмотности.
Добавлено спустя 2 часа 48 минут 41 секунду:
Все читаете и читаете (тему), нет бы написали чего нибудь...
Самое забавное что в fpc уже есть все необходимые механизмы для реализации (ограниченного) мнж наследования, например, решим выше указанную задачу через интерфейсы:
объявляем интерфейс IAccessRight с методом getAccessRight(...) далее делаем
TForm1 = class(TForm, IAccessRight) и реализуем его (интерфейс) через FAccessRight класс TAccessRight (1) так как getAccessRight(...) сложен и в нем используется кучка приватных методов, ну или тупо реализуем их в TForm1(2) а в TTreeNode1 копипастим.
Недостатоки первого варианта: нельзя (при Form1: TForm1) написать Form1.getAccessRight(...) а можно либо Form1.FAccessRight.getAccessRight(...) либо (Form1 as IAccessRight).getAccessRight(...) оба выглядят криво, также если нужны разные реализации getAccessRight(...) надо придумывать механизмы чтоб TAccessRight это учитывал.
Во втором вызовы прямые но копипаст все портит, при изменении интерфейса много править.
А теперь представим следующую реализацию мнж наследования, объявляем:
TAccessRight = class и TForm1 = class(TForm, TAccessRight), компилятор смотрит — оба-на в TForm1 вторым указан класс TAccessRight, он автоматом объявляет интерфейс с тем-же именем и копирует реализацию из TAccessRight в TForm1 в итоге вместо TForm1 = class(TForm, TAccessRight) получаем TForm1 = class(TForm, TAccessRight-интерфейс) плюс поля и методы (которые вставляется перед собственными TForm1), более того методы из TAccessRight (технически) можно оверрайдить. Получаем как раз второй вариант решения, но гораздо меньше писать кода и т.д.
Оператор AS немного надо будет переделать, т.е., при (Form1 as TAccessRight) хоть и известно что TAccessRight класс но если в предках его не найдено то надо поискать в таблице интерфейсов с тем-же именем (IS аналогично)
И все нормально, в рамках текущих структур данных (VMT и т.д.)
Так что тезис - мнж наследование — зло - это от неграмотности.
sts писал(а):Самое забавное что в fpc уже есть все необходимые механизмы для реализации (ограниченного) мнж наследования
Cамое забавное, что если будет реализовано мн. наследование, что очень вряд-ли, то вот так делать точно не будут. Я думаю, не у кого нет сомнений, что реализовали бы и нет недопонимания как. Есть понимание, что не нужно.
sts писал(а):Так что тезис - мнж наследование — зло - это от неграмотности.
Нет. От опыта вылавливания багов, я думаю. Хотя... Пусть бы было - ни кто не заставляет множественно наследоваться.
Не важно как будет если будет, суть втом что уже сейчас можно сделать так и закроются все ситуации с которыми сталкивался я.
По мне так сокращение кода в разы значительно более снижает количество багов, чем гипотетические баги мнж наследования, в первом случае я не могу сократить код и будет реальное пространство для возникновения багов в процессе разработки, а во втором будет место для маневра и их минимизации.
По мне так сокращение кода в разы значительно более снижает количество багов, чем гипотетические баги мнж наследования, в первом случае я не могу сократить код и будет реальное пространство для возникновения багов в процессе разработки, а во втором будет место для маневра и их минимизации.
sts
короче Вам хочется лишнего сахара... в "objectPascal" его и так выше меры.
используйте interface и делегирование с агрегацией, как Вы описали выше и как это было задумано изначально.
Лишнего кода минимум.
короче Вам хочется лишнего сахара... в "objectPascal" его и так выше меры.
используйте interface и делегирование с агрегацией, как Вы описали выше и как это было задумано изначально.
Лишнего кода минимум.
сахару мало, нету как минимум параметризованных классов и аннотаций (как в джаве)
Добавлено спустя 5 минут 10 секунд:
вот по этому в LCL и получается удвоение экземпляров классов - как недостаток сахара
Добавлено спустя 5 минут 10 секунд:
вот по этому в LCL и получается удвоение экземпляров классов - как недостаток сахара
Если очень надо - лучше это сделать на уровне IDE или макроподстановки.
Если начнут в компилятор это встраивать, то он станет тормозной и сложный как с++
Если начнут в компилятор это встраивать, то он станет тормозной и сложный как с++
ОП, This is... PASCAL!!! 
это я так, на случай, если вы с чем-то путаете
это я так, на случай, если вы с чем-то путаете
Хм.. А если способ связи форм и прав доступа позволит такое сделать, то как насчёт AccessManager.GetAccessRight(Form1, ...), или даже просто GetAccessRight(Form1, ...)? Т.е. вынести методы работы с правами доступа из классов? При этом теоретически классы могут всё также реализовать интерфейсы, и GetAccessRight(Form1, ...) -- служить синтаксическим сахаром для (Form1 as IAccessRight).getAccessRight(...).
hinst писал(а):ОП, This is... PASCAL!!!
это я так, на случай, если вы с чем-то путаете
ну речь идет о Object Pascal, и неплохо было бы чтобы он развивался
Особенно если надо для 15 классов (описывающих предметную область) сделать списки на основе TList, как-то напрягает делать 15 копий одного и того же, меняя только типы некоторых методов, и это вместо одного класса TList<E> .
Последний раз редактировалось sts 24.11.2010 21:33:12, всего редактировалось 1 раз.
perlpunk писал(а):Если начнут в компилятор это встраивать, то он станет тормозной и сложный как с++
В контексте FPC это звучит как издевательство.