Здравствуйте, Albatros, Вы писали:
A>Здравствуйте, batu, Вы писали: A>Надо много читать. A>Перечень использованногй литературы и не только уже проработан.
Слабенький перечень..
Здравствуйте, Albatros, Вы писали:
A>Здравствуйте, batu, Вы писали:
B>>.Надо много читать. A>Перечень использованной литературы, и далеко не только, уже переработан
Завтра скину чего надо прочитать..
Здравствуйте, gandjustas, Вы писали:
G>Отлично, TFigure у тебя получился интерфейсом.
G>Никакой развесистой иерархии на нем ты не постороишь.
Уровень вложенности рекомендуется специально ограничивать тремя, иначе растет сложность. Это и у Макконнелла вроде есть и у ребят, что систематизировали шаблоны проектирования(GoF). У них весь их редактор текста был во многом построен на интерфейсах.
НО! В этом примере суперкласс TFigure не является интерфейсом, хотя бы потому, что:
а — имеет свойства
б — интерфейсы не поддерживают полиморфизма. Они при наследовании не получают и модифицируют фукционал, а параллельно дополняют. Здесь чистый полиморфизм.
в — Поэтому этокласс с абстрактными методами. Можно сделать не абстрактный метод, а виртуальный, что еще лучше, например так:
TFigure = class
private
function GetPerimetr(): real; virtual;
....
function TFigure.GetPerimetr(): real;
begin
raise Exception.Create('Нет реализации метода в ' + Self.ClassName);
end;
Теперь инвариант класса TFigure такой:
Все наследники обязаны иметь периметр. Вот и все, теперь это не интерфейс абсолютно. Еще раз: хорошая иерархия та, у которой суперкласс абстрактный и сами иерархии определяются тем, какие методы нужны будут.
Являясь Вечным Двигателем, Они приветствуют нашу наивность в попытках Его изобрести.
Да напомню для всех: Бертран Мейер выделяет 11 "легальных" способов наследования, в частности "грязное" — наследование, при котором подкласс не является подтипом, т.е. когда берется чисто функционал без АТД. Вот так вот оказывается бывает.
Являясь Вечным Двигателем, Они приветствуют нашу наивность в попытках Его изобрести.
Здравствуйте, Albatros, Вы писали:
A>Здравствуйте, samius, Вы писали:
S>>Интересует отношение многоугольника и прямоугольника, место ромба, квадрата в иерархии
A>Иерархия типов зависит от требуемых в системе методов. Поэтому любая, например:
A>
Здравствуйте, Albatros, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>Отлично, TFigure у тебя получился интерфейсом.
G>>Никакой развесистой иерархии на нем ты не постороишь.
A>Уровень вложенности рекомендуется специально ограничивать тремя, иначе растет сложность. Это и у Макконнелла вроде есть и у ребят, что систематизировали шаблоны проектирования(GoF). У них весь их редактор текста был во многом построен на интерфейсах. A>НО! В этом примере суперкласс TFigure не является интерфейсом, хотя бы потому, что: A>а — имеет свойства
Если в делфи интерфейсы не могут иметь свойства, то это не значит что так везде.
A>б — интерфейсы не поддерживают полиморфизма. Они при наследовании не получают и модифицируют фукционал, а параллельно дополняют. Здесь чистый полиморфизм.
Интерфейс как чисто абстрактный класс поддерживает полиморфизм
A>в — Поэтому этокласс с абстрактными методами. Можно сделать не абстрактный метод, а виртуальный, что еще лучше, например так:
Класс с абстрактными методами играет роль интерфейса.
A>
A>TFigure = class
A>private
A> function GetPerimetr(): real; virtual;
A>....
A>function TFigure.GetPerimetr(): real;
A>begin
A> raise Exception.Create('Нет реализации метода в ' + Self.ClassName);
A>end;
A>
Это ничего не меняет
A>Теперь инвариант класса TFigure такой: A>Все наследники обязаны иметь периметр. Вот и все, теперь это не интерфейс абсолютно. Еще раз: хорошая иерархия та, у которой суперкласс абстрактный и сами иерархии определяются тем, какие методы нужны будут.
С абстрактным методом все точно так же, с той лишь разницей что не наследуется реализация метода с исключением.
Здравствуйте, Albatros, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>Отлично, TFigure у тебя получился интерфейсом.
G>>Никакой развесистой иерархии на нем ты не постороишь.
A>Уровень вложенности рекомендуется специально ограничивать тремя, иначе растет сложность.
Не понимаю как это связано...
A>НО! В этом примере суперкласс TFigure не является интерфейсом, хотя бы потому, что: A>а — имеет свойства
C# с тобой не согласен. Если в делфи нельзя сделать в интерфейсе свойства, то это проблема делфи.
Ты же общий случай рассматриваешь.
A>б — интерфейсы не поддерживают полиморфизма. Они при наследовании не получают и модифицируют фукционал, а параллельно дополняют. Здесь чистый полиморфизм.
Что значит "интерфейсы не поддерживают полиморфизма"? Что ты имеешь ввиду под словом полиморфизм?
A>в — Поэтому этокласс с абстрактными методами. Можно сделать не абстрактный метод, а виртуальный, что еще лучше, например так: A>
A>TFigure = class
A>private
A> function GetPerimetr(): real; virtual;
A>....
A>function TFigure.GetPerimetr(): real;
A>begin
A> raise Exception.Create('Нет реализации метода в ' + Self.ClassName);
A>end;
A>
А зачем? перенести compile-time проверку в runtime?
A>Теперь инвариант класса TFigure такой: A>Все наследники обязаны иметь периметр. Вот и все, теперь это не интерфейс абсолютно. Еще раз: хорошая иерархия та, у которой суперкласс абстрактный и сами иерархии определяются тем, какие методы нужны будут.
Все равно я пока не вижу "иерархии", потому что на лице интерфейс и его реализации.
Аналогичные вещи, но гораздо более "красивым" способом можно получит в haskell.
Мне кажется, что все это бессмысленно, так как в каждом ООП языке свое ООП. Общая методолгия для меня совсем иное, нежели все сразу, что есть во всех языках. Скорее наборот — только то, что есть у большинства общепризнанных ООП языков. Общие черты, а не все в одном. Литературы море, в каждой свое ООП, стандарта нет. UML вообще иногда мозг взрывает, особенно как у Рембо с Блахой. Давайте прекратим бессмысленный спор. Для меня что-то между интерфейсом и классом имеющим реализацию методов называется классом. Наследование реализации == наследование классов, наследование декларации == наследованию интерфейсов. Как-то так.
Являясь Вечным Двигателем, Они приветствуют нашу наивность в попытках Его изобрести.
Здравствуйте, Albatros, Вы писали:
A>НО! В этом примере суперкласс TFigure не является интерфейсом, хотя бы потому, что: A>а — имеет свойства
Cупер! И ты хочешь что-то о типах писать?
Вам надо срочно изучить пару-тройку языков отличных от устаревших версий Дельфи.
Даже современные версии дельфи поддерживают свойства в интерфейсах. А уж разные там C#-ы и VB поддирживали их с рождения.
A>б — интерфейсы не поддерживают полиморфизма.
Прочитайте определение полиморфизма прежде чем делать подобные заявления.
A>Они при наследовании не получают и модифицируют фукционал, а параллельно дополняют. Здесь чистый полиморфизм.
После этих слов лично мне стало отчетливо ясно, что у вас ничего путного не выйдет. Вы не только имеете однобокие знания, основанные в основном на устаревших версиях Дельфи. Но даже в этих рамках вы умудряетесь делать феерично абсурдные суждения.
A>в — Поэтому этокласс с абстрактными методами. Можно сделать не абстрактный метод, а виртуальный, что еще лучше, например так:
A>
A>TFigure = class
A>private
A> function GetPerimetr(): real; virtual;
A>....
A>function TFigure.GetPerimetr(): real;
A>begin
A> raise Exception.Create('Нет реализации метода в ' + Self.ClassName);
A>end;
A>
А этот, с позволения сказать код, скомпилируется? Неужели Дельфи допускает виртуальные private-методы?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, samius, Вы писали:
S>Интерфейс как чисто абстрактный класс поддерживает полиморфизм
Почти уверен, что могут. Во-первых, Дельфи поддерживает дотнет где интерфейсы могут, а значит обязаны (для совместимости с другими языками) иметь свойства. Во-вторых, Дельфи начиная со второй версии поддерживает COM в котором так еж есть свойства.
A>>в — Поэтому этокласс с абстрактными методами. Можно сделать не абстрактный метод, а виртуальный, что еще лучше, например так: S>Класс с абстрактными методами играет роль интерфейса.
+1
A>>
A>>TFigure = class
A>>private
A>> function GetPerimetr(): real; virtual;
A>>....
A>>function TFigure.GetPerimetr(): real;
A>>begin
A>> raise Exception.Create('Нет реализации метода в ' + Self.ClassName);
A>>end;
A>>
S>Это ничего не меняет
По-моему — это просто бред какой-то. Приватный виртуальный метод — это нонсенс.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD> A>>TFigure = class
VD> A>>private
VD> A>> function GetPerimetr(): real; virtual;
VD> A>>....
VD> A>>function TFigure.GetPerimetr(): real;
VD> A>>begin
VD> A>> raise Exception.Create('Нет реализации метода в ' + Self.ClassName);
VD> A>>end;
VD> A>>
VD> S>Это ничего не меняет
VD> По-моему — это просто бред какой-то. Приватный виртуальный метод — это нонсенс.
Отчего же? В рамках одного модуля имеет смысл. Private это не строгий ограничитель, и на дружественные (находящиеся в одном модуле) он не действует. Для строгого ограничения (область класса) есть Strict Private.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, samius, Вы писали:
S>>Интерфейс как чисто абстрактный класс поддерживает полиморфизм
VD>Почти уверен, что могут. Во-первых, Дельфи поддерживает дотнет где интерфейсы могут, а значит обязаны (для совместимости с другими языками) иметь свойства.
AFAIR это специальная версия делфи была для разработки под дотнет.
VD> Во-вторых, Дельфи начиная со второй версии поддерживает COM в котором так еж есть свойства.
Вроде бы интерфейсы в делфи перекочевали именно из поддержки COM-а
VD>По-моему — это просто бред какой-то. Приватный виртуальный метод — это нонсенс.
Тоже глаз резануло, хотя на делфи до 5-ой версии работал. Нифига правда не помню о делфи кроме := и begin/end
Здравствуйте, hattab, Вы писали:
H>Отчего же? В рамках одного модуля имеет смысл. Private это не строгий ограничитель, и на дружественные (находящиеся в одном модуле) он не действует. Для строгого ограничения (область класса) есть Strict Private.
Причем тут модуль? Это модификатор доступа к члену класса. Виртуальный метод который нельзя переопределить смысла не имеет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD> Причем тут модуль? Это модификатор доступа к члену класса. Виртуальный метод который нельзя переопределить смысла не имеет.
Еще раз. Private это нестрогий ограничитель. Он не закрывает члены класса от дружественных классов (располагающихся в одном с ним модуле).
Я честно не проверял, но уверен, что скомпелится. Это не стрикт приват. Хотя соглашусь, более грамотно в протектед. Я год просто на дельфях не работал, поэтому про свойства забыл у интерфейсов. Но ведь если есть свойства, следовательно могут быть сетеры и гетеры. А если еще, по вашему мнению, полиморфизм как у наследования классов, то чем они от классов отличаются?
Являясь Вечным Двигателем, Они приветствуют нашу наивность в попытках Его изобрести.
