Здравствуйте, Leshi, Вы писали:
L>Здравствуйте, LuciferMoscow, Вы писали:
LM>>Здравствуйте, Leshi, можешь привести пример, где не обойтись без множественного наследования? Наиболее реальный L>Я могу привести пример, где множественное наследование будет самым элегантным способом.
Я этого и хочу
Здравствуйте, LuciferMoscow, Вы писали:
L>>Я могу привести пример, где множественное наследование будет самым элегантным способом. LM>Я этого и хочу
Хорошо, из недавнего.
У меня есть свой класс, который отображает дерево. Каждый его элемент это тоже класс (думаю понятно почему). Есть некоторый функционал в виде древовидной иерархии (хранилище данный поверх БД). Там, соответственно, то же есть своя нода. Функционал используется как для отображения пользователю (UI) так и для доступа к БД в некотором сервисе. Так вот, в UI приложении использовать множественное наследование будет самым элегантным способом (имхо).
Поясню почему. Во-первых, сласс отображающий дерево я использую не только в одном проекте (да и не в однм месте), поэтому менять его под конкреные нужды не хочется. Во-вторых, сохранение и загрузка из БД при отображении не играет никакой роли, главное понять что отображать надо. В результате создаем производную ноду в виде
class MyNode: public TreeNode, public StoreNode
и переопределяем виртуальные методы tnGetTitle(), tnGetImage(), tnSetTitle(). Все готово, остальной функционал уже реализован. Через интерфейсы пришлось бы давольно много методов определять для UI и БД.
Leshi пишет:
>class MyNode: public TreeNode, public StoreNode > > и переопределяем виртуальные методы tnGetTitle(), tnGetImage(), > tnSetTitle(). Все готово, остальной функционал уже реализован. Через > интерфейсы пришлось бы давольно много методов определять для UI и БД.
class MyNode : public ITreeNode, public IStoreNode
{
TreeNodeDefaultImpl nodeImpl;
StoreNodeDefaultImpl storeImpl;
public:
void TreeNodeMethod() //Delegate methods
{
nodeImpl.TreeNodeMethod();
}
};
То бишь заменяем наследование делегированием в тех редких случаях, когда
это нужно. В IDEA для Java причем генерация делегирующих стабов
автоматизирована.
Здравствуйте, Leshi, Вы писали:
L>Хорошо, из недавнего. L>У меня есть свой класс, который отображает дерево. Каждый его элемент это тоже класс (думаю понятно почему). Есть некоторый функционал в виде древовидной иерархии (хранилище данный поверх БД). Там, соответственно, то же есть своя нода. Функционал используется как для отображения пользователю (UI) так и для доступа к БД в некотором сервисе. Так вот, в UI приложении использовать множественное наследование будет самым элегантным способом (имхо). L>Поясню почему. Во-первых, сласс отображающий дерево я использую не только в одном проекте (да и не в однм месте), поэтому менять его под конкреные нужды не хочется. Во-вторых, сохранение и загрузка из БД при отображении не играет никакой роли, главное понять что отображать надо. В результате создаем производную ноду в виде L>
class MyNode: public TreeNode, public StoreNode
L>и переопределяем виртуальные методы tnGetTitle(), tnGetImage(), tnSetTitle(). Все готово, остальной функционал уже реализован. Через интерфейсы пришлось бы давольно много методов определять для UI и БД.
Очень субъективно. Я бы, например, принципиально не стал бы в одном классе мешать загрузку из БД и элемент UI. По-мне — это плохой дизайн, так, что насчет элегантности — не согласен. Если разделить эти вещи по разным классам, что мне кажется более правильным, то множественно наследование не нужно.
Тем более раз из StoreNode не переопределяется ни одного метода, как я понял из примера, то изящества в наследовании не вижу вообще. Абсолютно монопенисуально — наследоваться или просто вызовать методы у члена класса.
Здравствуйте, Cyberax, Вы писали:
C>То бишь заменяем наследование делегированием в тех редких случаях, когда C>это нужно. В IDEA для Java причем генерация делегирующих стабов C>автоматизирована.
Я уже понял, что люди извращаются как хотят. В моем случае это привело бы к необоснованному затягиванию работы дня на три. У меня предков чуть больше десятка и у некоторых под полсотни методов. Ты тока представь во что превратиться класс с таким делегированием Даже думать не хочется. А так у меня получается, что я разбиваю на маленькие кусочки (даже там, где полсотни методов уже используется наследование). В результате классы имеют по три десятки методов (максимум), а последний имеет ну от силы полсотни (пока 14, но я еще не закончил).
В результате я понял, множественное наследование для меня является критичным элементом языка. Либо уж переходит совсем на процедурное программирование , либо множественное наследование. Полумеры мне не нравятся.
SK>Очень субъективно.
Аск! Я даже не спорю. Мне так больше нравиться. У меня есть небольшой набор сущьностей с которым я и работаю. По мне это лучше, чем куча всякого барохла которое делает маленький кусочек с одними и теме же данными. SK>Я бы, например, принципиально не стал бы в одном классе мешать загрузку из БД и элемент UI. По-мне — это плохой дизайн, так, что насчет элегантности — не согласен.
Уважаю чужое мнение. Но согласиться не могу. Данные там одинаковые. SK>Если разделить эти вещи по разным классам, что мне кажется более правильным, то множественно наследование не нужно.
Можно вообще уйти от ООП например. SK>Тем более раз из StoreNode не переопределяется ни одного метода, как я понял из примера, то изящества в наследовании не вижу вообще. Абсолютно монопенисуально — наследоваться или просто вызовать методы у члена класса.
Как я уже писАл в одном из предыдущих постов, это, имхо, вопрос стиля, который обзуждать не хочется.
Здравствуйте, Leshi, Вы писали:
L>Здравствуйте, StanislavK, Вы писали:
SK>>Тем более раз из StoreNode не переопределяется ни одного метода, как я понял из примера, то изящества в наследовании не вижу вообще. Абсолютно монопенисуально — наследоваться или просто вызовать методы у члена класса. L>Как я уже писАл в одном из предыдущих постов, это, имхо, вопрос стиля, который обзуждать не хочется.
А обсуждением чего ты тогда занимаешься?
Здравствуйте, Leshi, Вы писали:
L>Здравствуйте, Cyberax, Вы писали:
C>>То бишь заменяем наследование делегированием в тех редких случаях, когда C>>это нужно. В IDEA для Java причем генерация делегирующих стабов C>>автоматизирована. L>Я уже понял, что люди извращаются как хотят. В моем случае это привело бы к необоснованному затягиванию работы дня на три. У меня предков чуть больше десятка и у некоторых под полсотни методов. Ты тока представь во что превратиться класс с таким делегированием Даже думать не хочется. А так у меня получается, что я разбиваю на маленькие кусочки (даже там, где полсотни методов уже используется наследование). В результате классы имеют по три десятки методов (максимум), а последний имеет ну от силы полсотни (пока 14, но я еще не закончил). L>В результате я понял, множественное наследование для меня является критичным элементом языка. Либо уж переходит совсем на процедурное программирование , либо множественное наследование. Полумеры мне не нравятся.
Мне кажется, что проблема (если она, вообще есть ) в изначальном дизайне. В ATL, например, все на множественно наследовании, ну так они изначально разрабатывали дизан. Если примеры очень удачных библиотек, которые без него прекрастно обходятся, в той же java, например их много . Дизайн и взгляды на него менять трудно, так, что думаю, что это основная проблема.
Из языка множественное наследование выкинули не просто так, решили, что зла оно приносит больше: http://www.javaworld.com/javaqa/2002-07/02-qa-0719-multinheritance.html
Здравствуйте, StanislavK, Вы писали:
SK>А обсуждением чего ты тогда занимаешься?
Хотел поинтересоваться как люди без множественного наследования обходятся. Поинтересовался. Думал, что есть какой-то хитрый способ, о котором мне не известно. Выяснелось, что нет. Ну или пока не озвучили его. Теперь я полностью уверен, что C# и Java это как раз те языки, которыми я пользоваться не буду =)
Здравствуйте, StanislavK, Вы писали:
SK> Дизайн и взгляды на него менять трудно, так, что думаю, что это основная проблема.
Это точно. Правда я бы еще сказал и не нужно =) SK>Из языка множественное наследование выкинули не просто так, решили, что зла оно приносит больше: SK>http://www.javaworld.com/javaqa/2002-07/02-qa-0719-multinheritance.html
Что-то я про зло там не нашел (правда английский хромает, но все же)
The reasons for omitting multiple inheritance from the Java language mostly stem from the "simple, object oriented, and familiar" goal. As a simple language, Java's creators wanted a language that most developers could grasp without extensive training. To that end, they worked to make the language as similar to C++ as possible (familiar) without carrying over C++'s unnecessary complexity (simple).
Вот это кажется объяснение. Так вот, зла множественное наследование не приносит. Его отсутсвие обусловлено всего лишь стремлением упростить язык. Или я плохо понял?
Здравствуйте, LuciferMoscow, Вы писали:
LM>Здравствуйте, Leshi, можешь привести пример, где не обойтись без множественного наследования? Наиболее реальный
А что конкретно Вы понимаете под термином "множественное наследование"?
Что есть МН в Zonnon:
Реализация объектом нескольких интерфейсов это хорошо.
Пусть интерфейс может описывать кроме методов еще и переменные, которые есть ни что иное как свойства get, set, но благодаря "синтаксическому сахару" выглядят прямо как натуральные переменные. Вроде ничего плохого пока не произошло. Ведь реализация этих переменных оставлена за объектом реализующим этот интерфейс. Никакого скрытого от объекта-имплементатора состояния не добавлено — все оставлено под его контролем.
Пусть существует возможность дать некоторым методам этого интерфейса реализацию по умолчанию, которую объект-имплементатор может переопределить, а может и оставить.
Пусть существует возможность дать некоторым методам этого интерфейса финальную более не переопределяемую реализацию.
Такой "тяжелый" интерфейс в Active Oberon и в Zonnon называется ключевым словом DEFINITION. DEFINITION можно пересматривать (REFINE) — это как бы одиночное наследование интерфейсов. Объекты (OBJECT) могут имплементировать несколько DEFINITION — по сути это и является множественным наследованием, так как в частном случае каждый из DEFINITION может уже иметь (финальную) реализацию по умолчанию — т.е. OBJECT (множественно) унаследует эти реализации. Один OBJECT от другого OBJECT уже не наследуются, единицей (одиночного) наследования является только DEFINITION.
Концептуально, DEFINITION эквивалентна абстрактному С++ классу без переменных, без конструктора, без деструктора, а переменные сэмулированы с помощью абстрактных get/set методов.
Почему реализация МН в языке С++ вызывает нарекания:
Классы, от которых производится МН могут иметь свои собственные переменные. И особенно страшно — private переменные, то есть скрытое от класса-потомка состояние которое он сам контролировать не сможет.
Классы, от которых производится МН могут иметь конструкторы и деструкторы (в том числе изменяющие скрытое от класса-потомка состояние)
От класса уже имеющего несколько (множественных) предков можно еще раз (множественно) отнаследоваться.
все это может создать "гремучую смесь", способную если уж и не подорвать целостность системы, то запутать программиста — точно.
L>The reasons for omitting multiple inheritance from the Java language mostly stem from the "simple, object oriented, and familiar" goal. As a simple language, Java's creators wanted a language that most developers could grasp without extensive training. To that end, they worked to make the language as similar to C++ as possible (familiar) without carrying over C++'s unnecessary complexity (simple).
L>Вот это кажется объяснение. Так вот, зла множественное наследование не приносит. Его отсутсвие обусловлено всего лишь стремлением упростить язык. Или я плохо понял?
Усложнение языка и дазайна — это не зло? К тому же цитата не совсем полная, точнее выдернута из контекста, почитай следующий параграф.
Leshi пишет:
> C>То бишь заменяем наследование делегированием в тех редких случаях, > когда > C>это нужно. В IDEA для Java причем генерация делегирующих стабов > C>автоматизирована. > Я уже понял, что люди извращаются как хотят. В моем случае это привело > бы к необоснованному затягиванию работы дня на три. У меня предков > чуть больше десятка и у некоторых под полсотни методов.
Значит плохо проектировал. Я не припомню ситуации, когда единственность
наследования классов в Яве являлась для меня больгшой проблемой.
> Ты тока представь во что превратиться класс с таким делегированием > Даже думать не хочется. А так у меня получается, что я разбиваю на > маленькие кусочки (даже там, где полсотни методов уже используется > наследование). В результате классы имеют по три десятки методов > (максимум), а последний имеет ну от силы полсотни (пока 14, но я еще > не закончил).
В объектах этого мегакласса с кучей предков будут сотни методов — а это
признак плохого проектирования.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Почему реализация МН в языке С++ вызывает нарекания: СГ> Классы, от которых производится МН могут иметь свои собственные переменные. И особенно страшно — private переменные, то есть скрытое от класса-потомка состояние которое он сам контролировать не сможет.
Что в этом плохого? Если потомку необязательно знать о природе вещей в родителе, то можно и private (правда я сам это не приветствую и еще не разу не применял) СГ> Классы, от которых производится МН могут иметь конструкторы и деструкторы (в том числе изменяющие скрытое от класса-потомка состояние)
А еще могут быть методы, изменяющие скрытое от потомка состояние. СГ> От класса уже имеющего несколько (множественных) предков можно еще раз (множественно) отнаследоваться. СГ>все это может создать "гремучую смесь", способную если уж и не подорвать целостность системы, то запутать программиста — точно.
Прямо фильм ужасов Сидит в темноте бедный запутаный прогрммист и рвет на себе волосы! Имхо, натянуто за уши.
Практически любая сторонняя библиотека изменяет у себя внутренние состояния, недоступные для программиста ее использующего. Почему это считается нормальным? Я может быть не понимаю как работает fopen() для виндов, или fork() для юникса. И то, и другое изменяет внутреннее состояние системы. Ну так и что?
Здравствуйте, StanislavK, Вы писали:
SK>Усложнение языка и дазайна — это не зло?
Прости, но "Усложнение языка и дазайна" это вопрос субъективный. Приведу классический пример дизайна интерфейса (сильно сказано, но все же оно так и есть): Карандаш. Чтобы научиться им писать надо потратить много времени, но после этого с помощью карандаша (имеющего, кстати только две конструктивные особенности: можно держать в руке и тонцевым концом можно наносить линии) можно передавать различную информацию, как текстовую, так и графическую. Большенство людей не пользуются этими возможностями карандаша, но они есть. Так что "усложнение языка и дазайна" в данном случае надо читать как "расширение возможностей языка и дизайна". Тебя ведь никто не заставляет использовать даже ООП при программировании на С++, например. Можно использовать и процедурный и даже функциональный (правда уже поверх ООП) подход программирования. SK>К тому же цитата не совсем полная, точнее выдернута из контекста, почитай следующий параграф.
Прочитал. Остался при своем мнении, кроме того, тот, который привел я является началом, а следующий разъяснением что имелось в виду.
Здравствуйте, Cyberax, Вы писали:
C>Значит плохо проектировал. Я не припомню ситуации, когда единственность C>наследования классов в Яве являлась для меня больгшой проблемой.
Я рад за тебя. А у меня такое случилось.
C>В объектах этого мегакласса с кучей предков будут сотни методов — а это C>признак плохого проектирования.
Зато получается быстро. Я ни в одном месте не исользую мекапотомпа напрямую. Каждая часть делает приведение его к тому, с чем оно умеет работать и с этим работает. Мне так больше нравиться.
Leshi пишет:
> C>В объектах этого мегакласса с кучей предков будут сотни методов — а это > C>признак плохого проектирования. > Зато получается быстро.
Хочешь совет? Если везде наставить goto, то получится еще быстрее.
> Я ни в одном месте не исользую мекапотомпа напрямую.
А тогда зачем его делать, что мешает разбить его на несколько частей?
> Каждая часть делает приведение его к тому, с чем оно умеет работать и > с этим работает. Мне так больше нравиться.
Это неправильно. Таже TreeNode не должна наследоваться от StoreNode, а
должна ее аггрегировать. Посмотри как это сделано в Swing — весьма
элегантно и красиво.
Здравствуйте, Leshi, Вы писали:
L>Здравствуйте, StanislavK, Вы писали:
SK>>Усложнение языка и дазайна — это не зло? L>Прости, но "Усложнение языка и дазайна" это вопрос субъективный. Приведу классический пример дизайна интерфейса (сильно сказано, но все же оно так и есть): Карандаш. Чтобы научиться им писать надо потратить много времени, но после этого с помощью карандаша (имеющего, кстати только две конструктивные особенности: можно держать в руке и тонцевым концом можно наносить линии) можно передавать различную информацию, как текстовую, так и графическую. Большенство людей не пользуются этими возможностями карандаша, но они есть. Так что "усложнение языка и дазайна" в данном случае надо читать как "расширение возможностей языка и дизайна". Тебя ведь никто не заставляет использовать даже ООП при программировании на С++, например. Можно использовать и процедурный и даже функциональный (правда уже поверх ООП) подход программирования.
Неправильно мыслишь — к сожалению, заставляют. Я еще не разу в жизни не видел ни одного серьезного проекта написанного одним человеком. И, к сожалению, чем больше возможностей языка, тем больше возможности у людей написать такое чего писать не стоит.
Hello, Leshi!
You wrote on Thu, 17 Mar 2005 10:23:05 GMT:
SK>> Усложнение языка и дазайна — это не зло? L> Прости, но "Усложнение языка и дазайна" это вопрос субъективный. Приведу L> классический пример дизайна интерфейса (сильно сказано, но все же оно L> так и есть): Карандаш. Чтобы научиться им писать надо потратить много L> времени, но после этого с помощью карандаша (имеющего, кстати только две L> конструктивные особенности: можно держать в руке и тонцевым концом можно L> наносить линии) можно передавать различную информацию, как текстовую, L> так и графическую. Большенство людей не пользуются этими возможностями L> карандаша, но они есть. Так что "усложнение языка и дазайна" в данном L> случае надо читать как "расширение возможностей языка и дизайна". Тебя L> ведь никто не заставляет использовать даже ООП при программировании на L> С++, например. Можно использовать и процедурный и даже функциональный L> (правда уже поверх ООП) подход программирования.
На самом деле там усложнение дизайна для поддержки множественного
наследования потребовалось бы довольно сильное. Поскольку у всех объектов
общий предок, то множественное наследование автоматически превращается в
виртуальное. Которым даже в С++ стараются без острой необходимости не
пользоваться.
With best regards, Sergey.
Posted via RSDN NNTP Server 1.9
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Даже думать не хочется. А так у меня получается, что я разбиваю на маленькие кусочки (даже там, где полсотни методов уже используется наследование). В результате классы имеют по три десятки методов (максимум), а последний имеет ну от силы полсотни (пока 14, но я еще не закончил).
, либо множественное наследование. Полумеры мне не нравятся.
