Здравствуйте, Alexey Chen, Вы писали:
AC>Зачем нужны иерархии реализаций? Не абстракных интерфейсов, а именно полноценных реализаций. Это когда конкретные классы публично наследуются. AC>Как бы исчерпывающего ответа я не знаю. Так, на пальцах и небольших примерах. Может кто-то обьяснит это фундаментально?
Прагматический ответ:
Чтобы всю реализацию [класса-предка] не переписывать [в наследнике] с нуля ради какого-то тюнинга или расширения.
А публичность — чтобы в наследнике не переписывать с нуля интерфейсы предка.
struct IX { ... };
struct IY { ... };
class Base : public IX, public IY
{
public:
nonvirtual_api();
...
};
class Derived_1 : public IX, public IY
{
Base* impl; // агрегация как альтернатива наследованию
...
// копируем интерфейс и реализацию (хотя бы в виде шлюзов к impl)
};
class Derived_2 : private Base,
// копируем интерфейсpublic IX, public IY,
...
{
public:
// копируем интерфейсusing Base::nonvirtual_api();
...
};
Здравствуйте, Кодт, Вы писали:
К>Наследование в прагматическом виде — это
реализации
К>- берём базовый подобъект К>- берём надстройку К>- с т.з. базового подобъекта надстройка является агрегатом К>- тривиально решаем задачу создания объекта (в одном куске памяти) и налаживания связей между базой и надстройкой (таблицы виртуальных функций). К>То же самое можно сделать и вручную, вопрос лишь в цене.
Прочитал... пришла в голову идея. Наследование реализации — простейший структурный паттерн роддерживаемый на уровне языка (в большенстве OO языков)
Здравствуйте, alexeiz, Вы писали:
A>"Alexey Chen" wrote: >> Сразу вспоминается старый прикол про то что наследование убивает >> инкапсуляцию.
A>Каким это образом наследование убивает инкапсуляцию? Если у тебя базовый класс инкапсулирует внутренности private доступом, то никаким образом ты не расширишь доступ в наследуемом классе.
class Потомок : private База
Это означает что _потомок_ знает о структуре базы. Инкапсуляция нарушена, поскольку информация о реализации используется другим типом обьектов.
Но если потомок знает о базе не больше чем любой другой класс, то это просто два разных обьекта с одним интерфейсом. Ну и один, например, делегирует вызовы другому. Только возникает совершенно логичный вопрос, а чем конкретно эта база для этого потомка отличается от любой другой базы с тем же интерфейсом?
Вопрос на самом деле очень интересный. Отсюда следует, что используя в этом случае наследование без необходимости обратной связи, ты просто устанавливаешь совершенно ненужную жёсткую связь между двумя типами обьектов.
При наличии же обратной связи ('шаблонный метод'), такое наследование играет чисто имплементационное значение. Просто такой структурный паттерн поддерживается языком и обеспечивает минимум оверхеда на обратную связь, но и увеличивает жёсткость системы.
Здравствуйте, alexeiz, Вы писали:
>> Это означает что _потомок_ знает о структуре базы. Инкапсуляция >> нарушена, поскольку информация о реализации используется другим типом >> обьектов.
A>Ты имеешь ввиду object layout? В таком случае это просто детали реализации. В принципе, можно придумать такой object model, чтобы object layout для потомка никак не зависел от базы.
>> Но если потомок знает о базе не больше чем любой другой класс, то это >> просто два разных обьекта с одним интерфейсом. Ну и один, например, >> делегирует вызовы другому. Только возникает совершенно логичный >> вопрос, а чем конкретно эта база для этого потомка отличается от >> любой другой базы с тем же интерфейсом?
A>Реализацией. Мы наследуем от конкретной базы в данном случае, потому что хотим, чтобы она имела определённую реализацию, определённое поведение. В свете отношения is-a мне это представляется логичным.
Видимо мы друг друга не поняли. Я имею в виду аттрибуты и методы базы. Если они представляют из себя некий публичный контракт (публичный для наследников), то наследник работает с этим контрактом и инкапсуляция не нарушается, но встаёт вопрос зачем наследование. Если наследник пользуется деталями реализации предка, то нарушается инкапсуляция. Для это не обязатльно завязываться на лейоут или напрямую лезть к полям, достаточно просто заложится на реализацию контракта наследования.
Если жёсткой связи между типами нет (по реализации) есть только связь по контракту, то наследование служит лиш реализационным механизмом делегирования и обратного вызова, накладывая при этом невсегда нужную жёсткую связь. Получается что наследнику реализация базы не важна (инкапсуляция не нарушается), но важна клиенту связки наследник-база. И что мешает при необходимости сменить базу? Наследование и мешает, потому как идёт в разрез с реальностью, а именно независимостью этих типов. Когда в предметной области такие связи явно заданы (is-a) то такой задачи как смена базы (в рамках предметной области) не возникнет, но всёравно может возникнуть в процессе рефекторинга и переиспользования кода. Кто-то (вроде Буч) писал, что прогу можно анализировать как по классам, так и по обьектам. И, ИМХО, наследование неразрушающее инкапсуляцию со стороны выглядит просто как композиция из отдельных обьектов.
Здравствуйте, Кодт, Вы писали:
К>Прагматический ответ: К>Чтобы всю реализацию [класса-предка] не переписывать [в наследнике] с нуля ради какого-то тюнинга или расширения.
Не ну это я знаю.... это и есть на пальцах Хочется большого и чистого, но не слона, а такое фундаментальное обьяснение чтобы уж совсем фундаментально. Получается что наследование нужно только лишь для переиспользования кода? И если бы можно было автоматически делегировать вызовы реализуемого интерфейса в агрегат, то наследование было бы не нужно?
К>А публичность — чтобы в наследнике не переписывать с нуля интерфейсы предка. К>[c] К>struct IX { ... }; К>struct IY { ... };
Сразу вспоминается старый прикол про то что наследование убивает инкапсуляцию. Вот интересно в строго типизированных языках вообще можно сделать приватное наследование (реализации) с сохранением публичного интерфейса? Нда, сказанул. Это вообще на что может быть похожим?
Здравствуйте, Alexey Chen, Вы писали:
AC>Получается что наследование нужно только лишь для переиспользования кода? И если бы можно было автоматически делегировать вызовы реализуемого интерфейса в агрегат, то наследование было бы не нужно?
Наследование реализации нужно именно для переиспользования кода. Делегирование вызовов это и есть наследование реализации.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
AC>>Получается что наследование нужно только лишь для переиспользования кода? И если бы можно было автоматически делегировать вызовы реализуемого интерфейса в агрегат, то наследование было бы не нужно? ANS>Наследование реализации нужно именно для переиспользования кода. Делегирование вызовов это и есть наследование реализации.
Хм, то есть широко известный критерй мадам Лисков отступает перед прагматикой? Или как?
Иначе говоря, иерархия наследования реализаций есть ни что иное как фабрика модулей.
Интересно вот стало, а что такое вообще наследование? Что об этом говорят классики?
И как это сочитается с наследованием реализации для переиспользования?
Здравствуйте, Alexey Chen, Вы писали:
К>>Прагматический ответ: К>>Чтобы всю реализацию [класса-предка] не переписывать [в наследнике] с нуля ради какого-то тюнинга или расширения. AC>Не ну это я знаю.... это и есть на пальцах Хочется большого и чистого, но не слона, а такое фундаментальное обьяснение чтобы уж совсем фундаментально. Получается что наследование нужно только лишь для переиспользования кода? И если бы можно было автоматически делегировать вызовы реализуемого интерфейса в агрегат, то наследование было бы не нужно?
К>>А публичность — чтобы в наследнике не переписывать с нуля интерфейсы предка. К>>[c] К>>struct IX { ... }; К>>struct IY { ... };
AC>Сразу вспоминается старый прикол про то что наследование убивает инкапсуляцию. Вот интересно в строго типизированных языках вообще можно сделать приватное наследование (реализации) с сохранением публичного интерфейса? Нда, сказанул. Это вообще на что может быть похожим?
Мнэээ. Кроме прочего, наследование предоставляет базовому классу интерфейс реализации (виртуальные функции, перекрытые у потомка).
Разумеется, то же самое можно добиться и при агрегировании: отдать агрегату ссылку на реализацию внутренних фич (необязательно на себя, кстати).
Но каким бы затейливым способом не было всё это сделано (наследование, агрегирование, делегирование, чёрт в ступе) снаружи это всё равно будет выглядеть в соотвествии с Лисковой. Если один такой клубок тесно связанных объектов можно заменить другим клубком — то эти клубки выступают в отношении суперкласс-субкласс.
Здравствуйте, Alexey Chen, Вы писали:
AC>Не ну это я знаю.... это и есть на пальцах Хочется большого и чистого, но не слона, а такое фундаментальное обьяснение чтобы уж совсем фундаментально. Получается что наследование нужно только лишь для переиспользования кода? И если бы можно было автоматически делегировать вызовы реализуемого интерфейса в агрегат, то наследование было бы не нужно?
В принципе да. Если есть отдельно наследование только интерфейсов и наследование только реализаций, то без классического наследования вполне можно прожить.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Alexey Chen, Вы писали:
AC>>Не ну это я знаю.... это и есть на пальцах Хочется большого и чистого, но не слона, а такое фундаментальное обьяснение чтобы уж совсем фундаментально. Получается что наследование нужно только лишь для переиспользования кода? И если бы можно было автоматически делегировать вызовы реализуемого интерфейса в агрегат, то наследование было бы не нужно?
AVK>В принципе да. Если есть отдельно наследование только интерфейсов и наследование только реализаций, то без классического наследования вполне можно прожить.
Да можно конечно. Только ведь так делают очень редко. Часто бывает совмещение интерфейса и реализации в одном дереве. И интерфейсы то часто бывают статические. Вот нигде не видел понятного обьяснения почему что-то делают так, а что-то иначе. Всё сводится к 'жопой чуствую что верно'. Но это же ведь не аргумент. Когда я пишу код, перед мной всегда стоит выбор из нескольких вариантов. И думаю, каждый с этим сталкивается, но нормального критеория кроме, 'когда-то я делел так и мне понравилось'.... вообще-то нету, такого.
Или у кого есть?
Вот к примеру, что-то типа
совершенно абстракный пример, просто демонстрирующий идею
struct Base
{
virtual DoIt();
}
struct Derived1 : Base
{
DoIt()
{
// bla-bla-bla
Base::DoIt()
}
}
struct Derived2 : Derived1
{
DoIt()
{
// bla-bla-bla
Derived1::DoIt()
}
}
Почему и зачем используется именно иерархия классов совмещяющих в себе реализацию и интерфейс при этом использующая для рализации логики публичный интерфейс базы? Это ведь даже правильно, в том смысле что не разрушает инкапсуляцию, но почему именно наследовние реализации? Что является тем агрументом который влияет на выбор такого или какого-то иного решения?
Один из критериев уже предложил Максим (jazzer) — отношение 'is-a'. Но опять же, это ведь только критерий допустимости. Или нет?
Здравствуйте, Alexey Chen, Вы писали:
AC>Да можно конечно. Только ведь так делают очень редко. Часто бывает совмещение интерфейса и реализации в одном дереве.
Тем не менее качественные реализации тяготеют все же к вынесению модели. МС вот правда это ну очень не любит делать, отделяемые модели в фреймворке к примеру можно пересчитать по пальцам одной руки. В вот в Java для всех относительно свежих стандартов это норма.
Здравствуйте, Кодт, Вы писали:
К>Мнэээ. Кроме прочего, наследование предоставляет базовому классу интерфейс реализации (виртуальные функции, перекрытые у потомка).
Имеется в виду 'шаблонная функция'? Я предлагаю хоть частично пользоваться доступной терминологией, ну хотябы из тех облостей ОО в которых она вообще существует, более менее известна, и хоть как-то устоялось в нашем сообществе. Книгу от GoF, всёравно все читали. Как впрочем и Буча, но у него терминалогия нстолько расмыта, что ею пользоваться надо ну очнь осторожно.
К>Разумеется, то же самое можно добиться и при агрегировании: отдать агрегату ссылку на реализацию внутренних фич (необязательно на себя, кстати).
Вот мне и интересно, почему (и когда) выбор падает на наследование и 'шаблонную функцию', а не на декоратора, стратегии или наблюдателя (сигналы)? К примеру при добавлении к сообщению заголовка или обработке OnClick.
Как бы ясно, что есть противопоставление, обьекта как монолитной матрёшки сущностей и как композита заменяемых слабосвязанных и самодостаточных элементов. Но не понятен критерий выбора.
Здравствуйте, AndrewVK, Вы писали:
AVK>Тем не менее качественные реализации тяготеют все же к вынесению модели. МС вот правда это ну очень не любит делать, отделяемые модели в фреймворке к примеру можно пересчитать по пальцам одной руки. В вот в Java для всех относительно свежих стандартов это норма.
Может проблема в сложности управления жизненым циклом на C++ (шарпом я не очень интересуюсь) ?
Здравствуйте, Alexey Chen, Вы писали:
AVK>>Тем не менее качественные реализации тяготеют все же к вынесению модели. МС вот правда это ну очень не любит делать, отделяемые модели в фреймворке к примеру можно пересчитать по пальцам одной руки. В вот в Java для всех относительно свежих стандартов это норма.
AC>Может проблема в сложности управления жизненым циклом на C++ (шарпом я не очень интересуюсь) ?
Нет, проблема в том что МС сильно не любит сторонних реализаций. В примеру, если ты напишешь свой XML парсер, то весь повязанный на XML код с ним работать не сможет, так как совместимость по типам ты обеспечить не сможешь, только на уровне исходников.
Здравствуйте, Alexey Chen, Вы писали:
К>>Мнэээ. Кроме прочего, наследование предоставляет базовому классу интерфейс реализации (виртуальные функции, перекрытые у потомка).
AC>Имеется в виду 'шаблонная функция'? Я предлагаю хоть частично пользоваться доступной терминологией, ну хотябы из тех облостей ОО в которых она вообще существует, более менее известна, и хоть как-то устоялось в нашем сообществе. Книгу от GoF, всёравно все читали. Как впрочем и Буча, но у него терминалогия нстолько расмыта, что ею пользоваться надо ну очнь осторожно.
Как бы. Паттерн "Шаблонная функция" — это то, что достигается посредством интерфейса реализации. Т.е. есть инструмент и есть практика его использования.
В какой-то степени (особенно, когда шаблонная функция вырождена) тут возникают другие паттерны — например, адаптер.
Базовый подобъект является шлюзом между пользователем и целым объектом-наследником.
К>>Разумеется, то же самое можно добиться и при агрегировании: отдать агрегату ссылку на реализацию внутренних фич (необязательно на себя, кстати). AC>Вот мне и интересно, почему (и когда) выбор падает на наследование и 'шаблонную функцию', а не на декоратора, стратегии или наблюдателя (сигналы)? К примеру при добавлении к сообщению заголовка или обработке OnClick.
Шаблонная функция (имхо) есть обобщение тех же декораторов, наблюдателей и стратегий. Когда возникает некое критическое количество обратных связей между начальником (носителем шаблонной функции) и подчинённым, про эти паттерны приходится забыть.
AC>Как бы ясно, что есть противопоставление, обьекта как монолитной матрёшки сущностей и как композита заменяемых слабосвязанных и самодостаточных элементов. Но не понятен критерий выбора.
Наследование в прагматическом виде — это
— берём базовый подобъект
— берём надстройку
— с т.з. базового подобъекта надстройка является агрегатом
— тривиально решаем задачу создания объекта (в одном куске памяти) и налаживания связей между базой и надстройкой (таблицы виртуальных функций).
То же самое можно сделать и вручную, вопрос лишь в цене.
Далее выясняется, что если есть иерархия классов, то физическим наследованием её реализовать проще. Хотя нас никто не обязывает: могут быть совершенно разнородные объекты, скрывающиеся за одинаковыми интерфейсами.
Пример: окна. Есть некая "натуральная" классификация (контролы, диалоги, фреймы и т.д.), причём можно эту иерархию воспроизвести буквально (скажем, кроссплатформенные оконные системы), а можно развести зоопарк (как это принято в Windows).
Поскольку виндоуз ориентирован на низкоуровневые и разнородные языки, физическое наследование невозможно. И оно заменяется "шнуровкой".
Здравствуйте, Кодт, Вы писали:
К>Шаблонная функция (имхо) есть обобщение тех же декораторов, наблюдателей и стратегий. Когда возникает некое
Ну, в общем я так же думаю
К>критическое количество обратных связей между начальником (носителем шаблонной функции) и подчинённым, про эти паттерны приходится забыть.
При наследовании: начальник это наследник, подчинённый — база?
Получается, что когда у начальника может быть подчинённый только одного типа (и/или ему требуется знание устройства подчинённого) и существуют они только вместе, то наследование реализации оптимальным образом обеспечивает такую связь. Да, логично. Плюсы очевидны, минус сильной сязи не важен — решение действительно хорошее.
Прочитал то что написал, и подумал:
Если при этом чуть-чуть забыть о слове наследование, то хорошо видно, что критери is-a для наследования релизации не работает. Задача у такого наследования другая. Это я к тому, что правильно ли говорить — я унаследовал (реализацию) потому, что наследник это тоже самое? Сдаётся мне, что это ни есть причина, причина была указана в твоём постинге.
Здравствуйте, Alexey Chen, Вы писали:
К>>Шаблонная функция (имхо) есть обобщение тех же декораторов, наблюдателей и стратегий. Когда возникает некое AC>Ну, в общем я так же думаю
К>>критическое количество обратных связей между начальником (носителем шаблонной функции) и подчинённым, про эти паттерны приходится забыть.
AC>При наследовании: начальник это наследник, подчинённый — база?
Наоборот. Носитель шаблонной функции — это база, которая в функции дёргает полиморфные функции, предоставленные наследником.
Однако, шаблонную функцию можно реализовать и другими способами, при которых связь между подобъектами достаточно сильна (например, при агрегировании). Поэтому я отвлёкся от слов "база-наследник", описывающих структуру, и подчеркнул функциональную (ролевую) природу.
О! Кстати говоря: наследование это структурный паттерн, а ш.ф. — функциональный. Вполне естественно, что некоторые структурные и функциональные паттерны тяготеют друг к другу.
AC>Получается, что когда у начальника может быть подчинённый только одного типа (и/или ему требуется знание устройства подчинённого) и существуют они только вместе, то наследование реализации оптимальным образом обеспечивает такую связь. Да, логично. Плюсы очевидны, минус сильной сязи не важен — решение действительно хорошее.
В паттерне ш.ф. наоборот: подчинённый полиморфен.
Однако да, есть такие ситуации, при которых тип подчинённого фиксируется.
Впрочем, "начальник" и "подчинённый" — это роли. По ходу дела части объекта могут меняться ролями: например, некоторый интерфейс реализован в базе (которая обращается за реализацией к наследнику), а другой интерфейс появляется только у наследника (который пользуется базой).
AC>Прочитал то что написал, и подумал: AC>Если при этом чуть-чуть забыть о слове наследование, то хорошо видно, что критери is-a для наследования релизации не работает. Задача у такого наследования другая. Это я к тому, что правильно ли говорить — я унаследовал (реализацию) потому, что наследник это тоже самое? Сдаётся мне, что это ни есть причина, причина была указана в твоём постинге.
По-моему, мы уже озвучивали эту мысль на форуме. Наследование и принадлежность (что такое субкласс: это подмножество некоего суперкласса) — различаются, причём наследник может как сузить класс, так и, наоборот, расширить.
Трактовка наследника как субкласса удобна для формального контроля типов (неявный down-casting). Однако наследник может по смыслу "не вписаться" в контракт предка; самый известный пример — это срезка при копировании.
Здравствуйте, Alexey Chen, Вы писали:
AC>Зачем нужны иерархии реализаций? Не абстракных интерфейсов, а именно полноценных реализаций. Это когда конкретные классы публично наследуются.
Они и не нужны. Вполне достаточно иметь иерархии абстрактных типов. Многократно переопределяемые методы тоже не нужны, достаточно иметь однократно определяемые абстрактные или пустые методы. Просто в абстрактном типе определяете абстрактный или пустой метод, а в каком-то из абстрактных же типов расширений этот метод определяете (однократно!!!) тогда когда понимаете, что в последующих расширениях это метод уже не будет изменяться так сказать "финализирован" один раз и навсегда. Добавлю к этому еще то что тип может быть объявлен абстрактным даже в том случае если у него нет (никогда не было или уже нет, поскольку они уже определены) абстрактных или пустых методов. Расширять конкретный тип смысла нет никакого — бери и создавай его объекты и устраивай композицию объектов. Не верьте тому кто скажет, что данный совет может привести к дублированию кода. Нет не может. Просто программировать надо уметь.
Здравствуйте, Сергей Губанов, Вы писали:
AC>>Зачем нужны иерархии реализаций? Не абстракных интерфейсов, а именно полноценных реализаций. Это когда конкретные классы публично наследуются.
СГ>Они и не нужны. <далее идёт описание технологии>. Просто программировать надо уметь.
Так ведь и вопрос-то был в том: зачем нужны иерархии реализаций, если и без них можно обойтись.
Ответ: затем, чтобы упростить жизнь разработчику, когда наследование реализации возможно и эффективно.
(В ряде случаев — например, в COM — оно невозможно; в ряде случаев — неэффективно).
"Alexey Chen" wrote: > Сразу вспоминается старый прикол про то что наследование убивает > инкапсуляцию.
Каким это образом наследование убивает инкапсуляцию? Если у тебя базовый класс инкапсулирует внутренности private доступом, то никаким образом ты не расширишь доступ в наследуемом классе. А вот если ты взял за правило использовать protected, то конечно унаследованному классу все становится открыто.
"Alexey Chen" <17658@users.rsdn.ru> wrote in message news:1253005@news.rsdn.ru > Здравствуйте, alexeiz, Вы писали: > >> "Alexey Chen" wrote: >>> Сразу вспоминается старый прикол про то что наследование убивает >>> инкапсуляцию. > >> Каким это образом наследование убивает инкапсуляцию? Если у тебя >> базовый класс инкапсулирует внутренности private доступом, то >> никаким образом ты не расширишь доступ в наследуемом классе. > > class Потомок : private База
Вообще-то, я имел ввиду даже public наследование.
> > Это означает что _потомок_ знает о структуре базы. Инкапсуляция > нарушена, поскольку информация о реализации используется другим типом > обьектов.
Ты имеешь ввиду object layout? В таком случае это просто детали реализации. В принципе, можно придумать такой object model, чтобы object layout для потомка никак не зависел от базы.
Но если мы дело с интерфейсами, то это вопрос совершенного другого типа. В таком случае потомок знает о базе, только то, что база позволяет ему узнать через public и protected интерфейсы. Отличается это от информации доступной всему остальному миру, только protected интерфейсом. В таком случае потомок узнаёт о базе больше именно через protected интерфейс.
> Но если потомок знает о базе не больше чем любой другой класс, то это > просто два разных обьекта с одним интерфейсом. Ну и один, например, > делегирует вызовы другому. Только возникает совершенно логичный > вопрос, а чем конкретно эта база для этого потомка отличается от > любой другой базы с тем же интерфейсом?
Реализацией. Мы наследуем от конкретной базы в данном случае, потому что хотим, чтобы она имела определённую реализацию, определённое поведение. В свете отношения is-a мне это представляется логичным.
Alexey Chen,
AC>Зачем нужны иерархии реализаций? Не абстракных интерфейсов, а именно полноценных реализаций. Это когда конкретные классы публично наследуются.
У меня был реальный пример когда это было нужно. Есть некий протокол, реализаций этого протокола аж 5 версий, и от версии к версии механизм взаимодействия немного меняется. Мне удалось реализовать протокол в единообразном виде, а различия вынести в стратегию.
Отличия весьма разношёрстные, например понятие "бесконечность" у версий 0 и 1 — это 999999 , а у остальных — это 0! Ещё пример: в версии 0 нет криптования, в версиях 1 и 2 — 128 бита, а версиях 4 и 5 — 256. Есть ещё алгоритмические отличия, но в принципе то же самое — до какой то версии обработка одним способом, а после — другим.
Полученная картинка очень органично укладывается в наследование реализации.
interface Strategy
{
int getInfinity();
EncryptParams getEncryptParams();
Path getPath(Graph g);
}
///////////////////////////////////////////////////////////////////////////
// все эти классы содержатся в одном файле, что удобно при сопровождении //
///////////////////////////////////////////////////////////////////////////class Strategy0 implements Strategy
{
int getInfinity() { return 999999;}
EncryptParams getEncryptParams() { return new EncryptParams(0);}
Path getPath(Graph g)
{
// get path, the graph actually must be tree
// return null, if it is not a tree or it is not connected
// else return path needed
}
}
class Strategy1 extends Strategy0
{
EncryptParams getEncryptParams() { return new EncryptParams(128);}
}
class Strategy2 extends Strategy1
{
int getInfinity() { return 0;}
Path getPath(Graph g)
{
// get path, the graph can be any but must not have negative cycle
// return null, if it is not a such graph or it is not connected
// else return path needed
}
}
class Strategy3 extends Strategy2
{
EncryptParams getEncryptParams() { return new EncryptParams(256);}
}
class Strategy4 extends Strategy3
{
}
AC>Как бы исчерпывающего ответа я не знаю. Так, на пальцах и небольших примерах. Может кто-то обьяснит это фундаментально?
Фундаментально? Это просто альтернатива методу Yank+Paste, глубже копать не имеет смысла.
Перекуём баги на фичи!
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
