"Поток сознания" о тестировании и программировании: Наследование... Полиморфизм..

среда, 12 марта 2014 г.

Наследование... Полиморфизм..

http://blogs.embarcadero.com/vsevolodleonov/2013/02/07/alex_reply_friendship/

Знаете что.. Вот не согласен я с Леоновым...

Скорее согласен с Алексеевым...

Особенно про "интерфейсы"...

Особенно если "вспомнить" про "примеси и АОП.

НЕТУ "чистого" дерева наследования. В СЛОЖНЫХ системах.

Я вот СЕЙЧАС одну такую "СЛОЖНУЮ" систему перебираю по винтикам и болтикам.

И там - чем дальше - тем больше возникают "боковые" ветки наследования.

Читай - "примеси" и АОП.

Я бы привёл пример. Но боюсь, что для "читающей публики" он слишком сложен.

А уж у "сокрытия" - ЕСТЬ ГЛУБОКИЕ КОРНИ.

Ещё про "аспекты"...

Задам несколько вопросов...

Автомобиль ИНКАПСУЛИРЕТ (агрегирует) колёса или наследуется от телеги?

Велосипед с автомобилем в КАКИХ отношениях?

А самолёт? Он агрегирует шасси или наследуется от телеги? Или от автомобиля? Или от велосипеда?

А винт? Самолёт наследует? Или агрегирует? Если наследует, то от кого?

А вот скажет корабль? Он агрегирует винт или наследует? От кого? От самолёта?

А вот реактивный самолёт? Он НАСЛЕДУЕТСЯ от самолёта "с винтом"?

А как же корабль?

А или реактивный самолёт? Он наследуется от ракеты? Или ракета наследуется от него?

А вот корабль-"ракета" он в каких отношениях с самолётом и ракетой?

А вот колёсный пароход? Он наследуется от корабля? Или корабль от него наследуется? Или колёсный пароход наследуется от телеги? Или от велосипеда? Или от автомобиля?

А реактивный автомобиль (такие тоже бывают) он от кого наследуется? От ракеты? Или от реактивного самолёта? Или от телеги? Или от корабля-"ракеты"?

Не устали ещё от вопросов?

Они ведь ТРИВИАЛЬНЫЕ :-)

И ТАКИХ вопросов - у МЕНЯ ещё МИЛЛИОН...

Скажу одно... ПРИМЕСИ.

Ещё РАЗ - ПРИМЕСИ и АОП.

Колёса, мотор, и т.д. и т.п. это НЕ НАСЛЕДОВАНИЕ и не "прямая" агрегация.. Это - АСПЕКТЫ. Это - АОП.

А насчёт "сокрытия".... Напишу ещё ВОТ ЧТО...

Есть РАЗНЫЕ категории ПОЛЬЗОВАТЕЛЕЙ Классов (механизмов)... Есть ТУПОЙ ПОЛЬЗОВАТЕЛЬ.. Есть профессиональный водитель.. Есть механик.. Есть ремонтник.. Есть человек, который ПРОИЗВОДИТ механизм... Или ещё работник на мойке.. Или заправщик на заправке...

Кому-то нужен доступ к колёсам.. Кому-то к мотору.. Кому-то к багажнику.. Кому-то к бачку омывателя.. Кому-то к бензобаку.. Кому-то ко всему из вышеперечисленного.. Кому-то к какому-то подмножеству...

Так что вопрос - вроде "простой", но СОВСЕМ НЕ ОЧЕВИДНЫЙ...

Friend скажете вы.. Отчасти.. Отвечу я... К Friend - есть МНОЖЕСТВО вопросов..

ПЕРВЫЙ - это то, что Friend указывается в БАЗОВОМ классе, а не во Friend'е... Если эту зависимость нарисовать на UML, То СРАЗУ ВИДНО, что "направление зависимости" - НЕПРАВИЛЬНОЕ... Friend НАДО указывать в САМОМ Friend'е, а не в базовом классе...

И это - ТОЛЬКО ОДИН ВОПРОС...

А их - МАССА...

Тема тут явно НЕДОРАБОТАНА...

Правда Вирт пытается её развивать в Модуле и Обероне... Если я правильно понимаю...

И вот тут "в вопросе сокрытия" - возникает "мостик" к ИНТЕРФЕЙСАМ (о чём и говорит Алексеев (если я его правильно понял)).

Есть TSomeComlexMechanism - собственно "механизм".. И "НАД НИМ" есть НЕСКОЛЬКО РАЗЛИЧНЫХ "интерфейсов", регламентирующих "уровни доступа" - ISomeSimpleMechanism, ISomeComplexMechanisn, IWheels, IEngine, IDoor, IDoorAndWheels, IGasolineTank, IMetrics, IDevices etc.

(Кстати эта тема "отчасти развита" в FM с их "сервисами")

Мысль понятна? (Я правда САМ делаю - ПО-ДРУГОМУ).

Если у "пользователя" нашим механизмом "хватило мозгов" получить соответствующий интерфейс например IEngine - то это ЗНАЧИТ (допускаю что так), что он ЗНАЕТ, что с ним ДЕЛАТЬ и КАК это ДЕЛАТЬ.

Примитивно - если у человека "хватил ума" снять крышку двигателя, то это значит, что он ЗНАЕТ, что с НИМ ДЕЛАТЬ.. Ну или он ПОЛНЫЙ ИДИОТ.. Такого - НЕ ИСКЛЮЧАЮ...

Посему - ещё раз... НЕТУ "общего дерева наследования" и "строгой иерархии" машин и механизмов.

ЕСТЬ "множество аспектов применения и реализации".

35 комментариев:

NameRec13 марта 2014 г. в 00:57
Думаю, основная неприятность с наследованием состоит в подсознательно неверном его позиционировании.
Для меня (и не только) наследование - суть, специализация, что бы там ни говорил Гради Буч (хотя, м.б. он и передумал с тех пор...) Если смотреть с этих позиций ситуация во многом проясняется. Ведь специализация подразумевает, что у потомка не может быть избыточных свойств.
В частности, ни в одном из вопросов я не увидел специализации, соответственно и наследования.

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

АОП? Эта тема весьма интересна. Но только как идея. Как концепция выделения сквозной функциональности.
Мне не очень нравится терминология АОП, мне кажется она уводит от сути. А суть же состоит в выражении алгоритмов посредством протоколов, где протоколом является последовательность событий, рассылаемых в известные объекты в известной последовательности. Кроме того, должна быть стандартизована схема установки обработчиков на эти события и возможность PassEvent в обработчиках (возможность вызова обработчиков, установленных *перед* текущим (ранее текущего): без этого - никуда.

Примеси? Я кажется начал понимать, почему эта тема пользуется популярностью в определённых кругах.
Для себя я обозначил область применения этой техники. По мне - она выглядит тяжеловесно, и ведёт к запутыванию кода, если применяется часто. На мой взгляд, это во многом уступает предыдущему, хотя в некоторых случаях (когда нужно выполнить идентичную специализацию нескольких классов) - реально приходит на помощь. Но в моей практике такое случается очень редко, чаще всего, вследствие груза "навязанной" архитектуры (VCL например), так что и применение этого подхода весьма ограничено.

Что же до новых парадигм, "поиск которых продолжается"... Я думаю, мог бы кое-что предложить, но нужно сказать столько слов...
ОтветитьУдалить
Ответы
NameRec13 марта 2014 г. в 02:02
«АОП и "примеси" - ничего тяжеловесного я не вижу...»
-- Как-то я спросил Учителя: "Что можно сделать на Turbo Vision такого, чего нельзя на Object Professional?". Он мне ответил: "Ничего". Тогда я спросил, "Почему же Вы готовы отбросить наши наработки и почему выбрали Turbo Vision?". Он ответил: "Потому, что Turbo Vision - лучше".
Просто вспомнилось...
Ruby и Python. Могут - наверное, одинаково. В Ruby очень любят примеси, в Python... В них просто нет необходимости. Их нетрудно делать, но почему-то... Это просто ненужно.
Мы *никогда* не использовали примеси. Но я не говорю, что это плохо. Я просто знаю, как без них обходиться, а в случае, когда для меня они уместны, вижу изъяны в архитектуре, которые делают их применение желательным. "Знаю как обходиться" - это не "знаю, как выкрутиться". Есть другой способ расширения функциональности, я его описал вкратце выше. Этот способ работает не на уровне статичных классов, но на уровне динамически создаваемых объектов. Он гибче и, на мой взгляд, позволяет получить более простое и изящное решение.
Для меня примеси - это "предметная магия", лишняя сущность, если хотите. Из серии лишних сущностей, что не стоит множить сверх необходимости. И повторюсь, для меня существует типаж ситуаций (я его обозначил), в которых примеси - лучшее решение. И ещё повторюсь: это только для меня. Я ничего не утверждаю. Вообще: "Я не могу принять сторону - я не знаю никого, кто не прав" (c) БГ
ОтветитьУдалить
Ответы
Alex W. Lulin13 марта 2014 г. в 02:35
"И компилировать его с ключом "-y", о котором мало кто знает, потому, что это никому не нужно :-)"

-- я знаю :-)
ОтветитьУдалить
Ответы
Alex W. Lulin13 марта 2014 г. в 02:48
"Помню, меня позабавило, когда Всеволод мне как-то "указал" на построение форм по метаданным... А что, если я скажу, что у нас *все* без исключения формы строятся на основе метаданных, и большинство - только по ним, автоматически. Что поля-внешние ключи автоматически преобразуются в поля выбора из справочников/сущностей, что запросы к БД пользователь может "рисовать" сам, посредством инструмента, который проще QBE? Вот здесь и DDD, которым, как я понимаю, Вы интересуетесь."

:-) знакомо :-)
ОтветитьУдалить
Ответы
Alex W. Lulin13 марта 2014 г. в 23:12
2 Namerec.

При всём моём безграничном УВАЖЕНИИ к вам.

Вы "на самом деле" не "так просты", как хотите казаться.

Похоже, что вы "противник велосипедов", но ПРИ ЭТОМ вы САМИ "изобрели множество велосипедов". :-)

Я ДАВНО заметил ЭТО за собой - ЧЕМ БОЛЬШЕ ты делаешь на какой-то "почве", тем БОЛЕЕ КРИТИЧЕСКИ ты относишься к тому, что ДРУГИЕ делают на той же самой "почве".

Что по сути?

Вот ОЧЕНЬ ЖАЛЬ, что Вы не раскрываете СВОЕГО КОДА.

Хотя бы части его.

Вы зря "боитесь" или "опасаетесь".

НИКТО ничего не украдёт.

Что скажу до того "как я Вас понял".

Хотя Вы и "противник примесей", но Вы ИХ ИСПОЛЬЗУЕТЕ.

Если я правильно понял.

Вы создаёте объект в run-time и потом добавляете к нему делегатов, обеспечивающих те или иные аспекты.

Я же добавляю аспекты в compile-time.

Вот и вся разница?

Я прав?

Я правильно Вас понял?
ОтветитьУдалить
Ответы
Alex W. Lulin13 марта 2014 г. в 23:22
Я бы посмотрел на ваш TSBaseClass хотя бы "одним глазком"..

Можно и не публично? :-)

Там у Вас наверное что-то вроде Duck-Typing Python'а. Или "альтернатива RTTI". Некая "мапа" "имя метода"-"его делегат".

И на основе "делегатов" Вы "примешиваете" функциональность к объектам.

Или я СОВСЕМ заблуждаюсь?
ОтветитьУдалить
Ответы
NameRec14 марта 2014 г. в 00:56
«Вот ОЧЕНЬ ЖАЛЬ, что Вы не раскрываете СВОЕГО КОДА.»
-- Я не последний человек в фирме, многое сделал сам, но не я принимаю решения, что открывать, а что - нет.
Тем не менее, вероятнее всего, я очень скоро это сделаю.
Принципиальное одобрение директора уже есть, осталось уладить технические детали.
Думаю - на этой неделе.
ОтветитьУдалить
Ответы
NameRec14 марта 2014 г. в 00:57
Хотя Вы и "противник примесей", но Вы ИХ ИСПОЛЬЗУЕТЕ.»
-- Алексндр, давайте расставим точки над i.
1. Я *не* противник примесей - это технический приём с определённой областью применимости. Я её обозначил.
Использовать примеси более широко мы не видим необходимости и (в дополнение) видим опасность в увеличении сложности. Возможно, наличие инструментов, подобных Вашим, усложнение нивелирует.
2. Примеси и расширенное делегирование - параллельные вещи. Можно использовать и то и другое одновременно - это не противоречит решительно ничему.
Примешивание определено на классах, ввиду этого - статично. Вы *не сможете расширить* примесями функциональность класса в runtime, например, в зависимости от структуры таблицы, с которой объекту этого класса потребовалось работать в данный момент.
Расширенное делегирование определено на объектах и событиях. Оно динамическое по природе. "Каркас", протокол, реализует общая функциональность, расположенную на определённом уровне фреймворка. Каркас определяется набором событий, происходящих в определённых объектах, в определённой последовательности.
"Определённой" - значит, оговоренной, описанной (нарисованной на диаграмме последовательности, например), известной разработчику, который имеет право использовать это знание.
Протокол работы с объектами, реализующими каркас, подразумевает событие подготовки объекта, рассылаемое «в приложение» (очень грубо, поскольку м.б. в другой объект, в соединение с БД, например). В качестве параметра в это событие передаётся настраиваемый объект и, в ряде случаев, дополнительный контекст, опираясь на который в обработчиках события подготовки можно выполнить настройку.
Настройка подразумевает создание объектов-обработчиков, обрабатывающих события каркаса. Эти объекты часто имеют смысл только в контексте объекта (или объектов), определяющих каркас и не имеют смысла за его (контекста) рамками. Поэтому, чаще всего жизненный цикл этих объектов определяется временем жизни объектов, определяющих каркас.
Объекты-обработчики, жизненный цикл которых определяется объектами каркаса (они тоже могут быть объектами-обработчиками) называют симбиотами (или, жаргонно - «паразитами»).
ОтветитьУдалить
Ответы
NameRec14 марта 2014 г. в 00:58
Симбиот может существовать в контексте *любого* объекта, причём сам объект может не знать о его существовании. Ну, просто разработчик счёл необходимым так определить жизненный цикл симбиота.
Делается это одной строчкой, например, в конструкторе такого симбиота (статический вариант):
InstallEventHandler(Instance, ev_Terminate, Self.CloseSelf);
Или извне объекта-обработчика его можно сделать симбиотом:
InstallEventHandler(Instance, ev_Terminate, handler.CloseSelf);
Здесь:
[InstallEventHandler]: *процедура*, выполняющая установку метода-обработчика на событие, происходящее в контексте объекта
[Instance]: объекта, определяющий контекст — в общем случае, реализующий каркас или его часть.
[ev_Terminate]: идентификатор *стандартного* события, происходящего ***до*** освобождения Instance, ***до*** вызова его метода BeforeDestruction. В момент рассылки этого события Instance ещё работоспособен, но принято решение о его освобождении — вызван метод Free.
Для того, чтобы это сделать, требуются изменения в System. Нужно или Free изменить (вызвать CallBack, сохранённый в threadvar) или, что лучше, поправить _BeforeDestruction, например — так:
<-- code --
procedure dummy_BeforeDestruction(const Instance: TObject);
begin
end;

var
GLOBAL_BeforeDestruction: TBeforeDestructionProc = dummy_BeforeDestruction;

procedure SetGLOBAL_BeforeDestruction(proc: TBeforeDestructionProc);
begin
if Assigned(proc) then
GLOBAL_BeforeDestruction := proc;
end;

{$IFNDEF CPUX86}
procedure _BeforeDestruction(const Instance: TObject; OuterMost: ShortInt);
begin
if OuterMost > 0 then
begin
GLOBAL_BeforeDestruction(Instance);
Instance.BeforeDestruction;
end;
end;
… … …
-- code -->
[Self, handler]: объект-обрабочик, который становится симбиотом на уровне класса (в конструкторе) или за его пределами, динамически.
[CloseSelf]: метод, определённый в TSBaseClass. Реализация тривиальна: Self.Free.
ОтветитьУдалить
Ответы
NameRec14 марта 2014 г. в 00:58
«Вы создаёте объект в run-time и потом добавляете к нему делегатов, обеспечивающих те или иные аспекты.»
– Да.

«Я же добавляю аспекты в compile-time.»
– Ну, по крайней мере, мне так показалось :-) Вам виднее.

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

«Там у Вас наверное что-то вроде Duck-Typing Python'а. Или "альтернатива RTTI". Некая "мапа" "имя метода"-"его делегат".»
– Да, там есть аналог map – словарь. Только не {«имя события»: «делегат»}, а {«имя события»: «список обработчиков (делегатов)». Обработчики (делегаты в Вашей терминологии) получают управления в порядке, обратном тому, в котором они были установлены. Последним управление получает обработчик по-умолчанию, который может быть реализован на уровне каркаса.
Принципиальный момент, на котором я останавливался ранее. Рядом с InstallEventHandler определена процедура PassEvent(var AEvent: TEvent) предназначенная для применения исключительно в обработчиках. В случае её использования, управление будет передано всем обработчикам, установленным *до* (или ранее) текущего, после чего будет возвращено в текущий. Это даёт возможность обработчику-делегату получать управление как в пре-, так и в постпроцессе рассылки события, что делает ненужными события Before и After.
ОтветитьУдалить
Ответы
Alex W. Lulin14 марта 2014 г. в 01:07
Ну вообще говоря - из всего вышенаписанного - я ПОНЯЛ, что и КАК вы делаете. Мне - ПОНЯТНО. :-) "интерес" так сказать - "удовлетворён". Скажем так - МНЕ НРАВИТСЯ... Это как у Теплякова... :-) Мне нравится, что он пишет, и мне нравится, что Вы делаете. Хотя я и делаю "по-другому".
ОтветитьУдалить
Ответы
Alex W. Lulin14 марта 2014 г. в 01:16
Я только ОДНО не понял... ЗАЧЕМ ВАМ -y понадобился.. Это - "самое интересное".. Ну сделали свой "базовый класс", который поддерживает делегаты (это Ваш кстати термин), но зачем System.pas и TObject править?
ОтветитьУдалить
Ответы

Добавить комментарий

среда, 12 марта 2014 г.

Наследование... Полиморфизм..

35 комментариев:

среда, 12 марта 2014 г.