Мне тут понадобилось переписать заново одну старую програмулину (написанную на С++). И я занялся изучением новомодных тенденций. Хотелось идти в ногу со временем и использовать что-то современное (ладно, кандидатами были C# и Java). Но беда заключается в том, что в старом коде используется множественное наследование почти везде. В двух словах, там есть несколько базовых функционалов (десятка три), реализованных своими классами. А рабочие классы используют то, что им надо (обычно от 5 до 15 родителей) и переопределяют некоторые операции. Так вот возник вопрос, как же без множественного наследования люди обходятся? Поделитесь опытом
ЗЫ: Вопрос о выборе средства разработки уже не стоит, С++ однозначно.
Здравствуйте, Leshi, Вы писали:
L>Мне тут понадобилось переписать заново одну старую програмулину (написанную на С++). И я занялся изучением новомодных тенденций. Хотелось идти в ногу со временем и использовать что-то современное (ладно, кандидатами были C# и Java). Но беда заключается в том, что в старом коде используется множественное наследование почти везде. В двух словах, там есть несколько базовых функционалов (десятка три), реализованных своими классами. А рабочие классы используют то, что им надо (обычно от 5 до 15 родителей) и переопределяют некоторые операции. Так вот возник вопрос, как же без множественного наследования люди обходятся? Поделитесь опытом
L>ЗЫ: Вопрос о выборе средства разработки уже не стоит, С++ однозначно.
Дык если язык разработки будет С++ то зачем отказываться от множественного наследования ?
L>Так вот возник вопрос, как же без множественного наследования люди обходятся? Поделитесь опытом
— использовать интерфейсы
— хорошо проектировать иерархию наследования
— использовать включение классов с нужным функционалом и переадресацию вызовов на них (интерфейсы скрывают это от пользователей класса)
— ну и приходиться извращаться — использовать неявные преобразования, reflection
вобщем бывает тяжело без множественного наследования, но в большинстве случаев жить можно
Здравствуйте, _Obelisk_, Вы писали:
_O_>Дык если язык разработки будет С++ то зачем отказываться от множественного наследования ?
Дык поэтому и С++, что остальное без множественного наследования.
Здравствуйте, Banch, Вы писали:
L>>Так вот возник вопрос, как же без множественного наследования люди обходятся? Поделитесь опытом
B>- использовать интерфейсы
В данном случае интерфейсы описывают только что делать, а уж как приходится думать в реализации. Это, как бы это по-мягче, неудобно. B>- хорошо проектировать иерархию наследования
Хорошо уже не получается, приходится думать о том, куда это все запихать. Ведь если, допустим, у меня есть функционал записи на диск и функционал записи в базу данных это же две разные вещи. Объединять их в один класс нет надобности, а придется B>- использовать включение классов с нужным функционалом и переадресацию вызовов на них (интерфейсы скрывают это от пользователей класса)
Это, кажется, называется изврат? B>- ну и приходиться извращаться — использовать неявные преобразования, reflection B>вобщем бывает тяжело без множественного наследования, но в большинстве случаев жить можно
Ну не понимаю я, почему в таком случае C# и Java так рьяно отстаиваются их сторонниками. Это же сырые язяки получаются... (ща побъют)
Здравствуйте, Leshi, Вы писали:
B>>вобщем бывает тяжело без множественного наследования, но в большинстве случаев жить можно
L>Ну не понимаю я, почему в таком случае C# и Java так рьяно отстаиваются их сторонниками. Это же сырые язяки получаются... (ща побъют)
C# и Java — скоро станут устаревшими. Обратите внимание, например, на язык Zonnon (это потомок от языка Active Oberon for .NET). Там множественное наследование есть! Просто создатели C# и Java выплеснули вместе с водой и ребенка открестившись от множественного наследования в пользу интерфейсов испугавшись сложностей реализации множественного наследования в языке С++. Но, дело в том, что множественное наследование и язык С++ это вовсе не близнецы-братья, а разные вещи. Множественное наследование можно реализовать подругому, не так как в С++. В результате все вкусности множественного наследования в языке Zonnon присутствуют, в тоже самое время нет ни одного недостатка множественного наследования присущих реализации оного в С++.
Здравствуйте, Leshi, Вы писали:
B>>- использовать интерфейсы L>В данном случае интерфейсы описывают только что делать, а уж как приходится думать в реализации. Это, как бы это по-мягче, неудобно. B>>- хорошо проектировать иерархию наследования L>Хорошо уже не получается, приходится думать о том, куда это все запихать. Ведь если, допустим, у меня есть функционал записи на диск и функционал записи в базу данных это же две разные вещи. Объединять их в один класс нет надобности, а придется B>>- использовать включение классов с нужным функционалом и переадресацию вызовов на них (интерфейсы скрывают это от пользователей класса) L>Это, кажется, называется изврат?
Это называется агрегирование. Через него делается множественное как-бы-наследование в COM.
Здравствуйте, Leshi, Вы писали:
L>Мне тут понадобилось переписать заново одну старую програмулину (написанную на С++). И я занялся изучением новомодных тенденций. Хотелось идти в ногу со временем и использовать что-то современное (ладно, кандидатами были C# и Java). Но беда заключается в том, что в старом коде используется множественное наследование почти везде. В двух словах, там есть несколько базовых функционалов (десятка три), реализованных своими классами. А рабочие классы используют то, что им надо (обычно от 5 до 15 родителей) и переопределяют некоторые операции. Так вот возник вопрос, как же без множественного наследования люди обходятся? Поделитесь опытом
Как я обхожусь в Java: куча мелких компонентиков и Spring, их связывающий. Соответственно, вместо сильной зависимости наследование активно используется более слабая — композиция.
Здравствуйте, LuciferMoscow, Вы писали:
LM>Как часто ты используешь множественное наследование? Думаю далеко не в каждом проекте. Лично мне приходилось сталкиватся с ним <=2 раз за три года
За 10 лет у меня небыло ни одного проекта, где я не использовал бы множественного наследования. Хотя я слонен считать это стилем программирования (который обсуждать не буду)
Здравствуйте, Сергей Губанов, Вы писали:
СГ>C# и Java — скоро станут устаревшими.
Смело... СГ>Обратите внимание, например, на язык Zonnon
Маленький для меня. Лет через пять можно будет подумать. Вкладывать в него ресурсы (время и деньги) кажется мне слишком рисковым. Мне нужен более или менее успешний в коммерческом плане язык. Так что пока поищем (но не слишком уж активно) альнернативу С++ в других местах.
Leshi пишет: > СГ>Обратите внимание, например, на язык Zonnon <http://www.zonnon.ethz.ch/> > Маленький для меня. Лет через пять можно будет подумать. Вкладывать в > него ресурсы (время и деньги) кажется мне слишком рисковым. Мне нужен > более или менее успешний в коммерческом плане язык. Так что пока поищем > (но не слишком уж активно) альнернативу С++ в других местах.
Ну, в Eifell есть множественное наследование. Он есть для .Net.
--
Andrei N.Sobchuck
JabberID: andreis@jabber.ru. ICQ UIN: 46466235.
Сергей Губанов пишет:
> L>Ну не понимаю я, почему в таком случае C# и Java так рьяно > отстаиваются их сторонниками. Это же сырые язяки получаются... (ща побъют) > C# и Java — скоро станут устаревшими. Обратите внимание, например, на > язык Zonnon <http://www.zonnon.ethz.ch/> (это потомок от языка Active > Oberon for .NET). *Там множественное наследование есть!*
Которое является просто синтаксическим сахаром над интерфейсами. Ни
Java, ни .NET не запрещают использовать множественное наследование, они
лишь запрещают множественное наследование классов на уровне CLI.
Множественно наследование на уровне прикладного языка замечательно
выражается с помощью интерфейсов.
Здравствуйте, prVovik, Вы писали:
К>>Это называется агрегирование. V>Точнее, делегирование...
Таки агрегирование! Именно агрегирование в связке с интерфейсами (или даже без них) является заменой (а точнее эквивалентом) множествунному наследованию.
Здравствуйте, softilium, Вы писали:
S>Таки агрегирование! Именно агрегирование в связке с интерфейсами (или даже без них) является заменой (а точнее эквивалентом) множествунному наследованию.
точно, точно...
VladD2 пишет: > ANS>Ну, в Eifell есть множественное наследование. Он есть для .Net. > > Проблемы тоже есть. Реализация не компонентная. По сути просто создается > третий класс в который копируются два базовых.
Это почему не компонентная? Как по мне, то реализация вполне нормальная.
--
Andrei N.Sobchuck
JabberID: andreis@jabber.ru. ICQ UIN: 46466235.
Здравствуйте, LuciferMoscow, Вы писали:
LM>Здравствуйте, Leshi, можешь привести пример, где не обойтись без множественного наследования? Наиболее реальный
Я могу привести пример, где множественное наследование будет самым элегантным способом. Я даже не пытаюсь спорить о том, что без множественного наследования нельзя обойтись. Вконце концов в машинном коде понятия объект вообще не существует
Здравствуйте, 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 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Cyberax, Вы писали:
>> C>В объектах этого мегакласса с кучей предков будут сотни методов — а это >> C>признак плохого проектирования. >> Зато получается быстро. C>Хочешь совет? Если везде наставить goto, то получится еще быстрее.
Вот как раз если наставить goto получиться медленно. Быстро проектировать и реализовывать получается.
>> Я ни в одном месте не исользую мекапотомпа напрямую. C>А тогда зачем его делать, что мешает разбить его на несколько частей?
Разбивая на несколько частей я получаю много разрозненных сущьностей. Это мне не нравиться.
>> Каждая часть делает приведение его к тому, с чем оно умеет работать и >> с этим работает. Мне так больше нравиться. C>Это неправильно. Таже TreeNode не должна наследоваться от StoreNode
Она этого не делает. C>, а должна ее аггрегировать.
И этого, заметь, то же. C>Посмотри как это сделано в Swing — весьма элегантно и красиво.
смотрел. Имхо, убого. Выкрутились, несколько красивых приемов есть. Но в целом убого.
Здравствуйте, StanislavK, Вы писали:
SK>Неправильно мыслишь — к сожалению, заставляют. Я еще не разу в жизни не видел ни одного серьезного проекта написанного одним человеком. И, к сожалению, чем больше возможностей языка, тем больше возможности у людей написать такое чего писать не стоит.
Значит плохо работают проект-менеджеры. Надо подбирать людей равной квалификации, тогда все будет хорошо.
Здравствуйте, Sergey, Вы писали:
S>На самом деле там усложнение дизайна для поддержки множественного S>наследования потребовалось бы довольно сильное. Поскольку у всех объектов S>общий предок, то множественное наследование автоматически превращается в S>виртуальное.
Это похоже на проблемы индейцев, которые шерифа, как известно, не касаются =) Другими словами, просто кишка тонка была сделать множественное наследование? Ну похоже. S>Которым даже в С++ стараются без острой необходимости не S>пользоваться.
Да. Но если острая необходимость возникает, тогда деваться некуда. Я правда не разу не пользовался, но помню, что есть и такое.
Leshi пишет:
>>> Я ни в одном месте не исользую мекапотомпа напрямую. > C>А тогда зачем его делать, что мешает разбить его на несколько частей? > Разбивая на несколько частей я получаю много разрозненных сущьностей. > Это мне не нравиться.
А с чего это они должны быть объединены?
> C>Посмотри как это сделано в Swing — весьма элегантно и красиво. > смотрел. Имхо, убого. Выкрутились, несколько красивых приемов есть. Но > в целом убого.
Читать про паттерн MVC. ОООООЧень многие ошибки проектирования как раз и
возникают из-за незнания этого паттерна.
Здравствуйте, Cyberax, Вы писали:
C>А с чего это они должны быть объединены?
Потому что по сути это одно и то же. C>Читать про паттерн MVC. ОООООЧень многие ошибки проектирования как раз и C>возникают из-за незнания этого паттерна.
м-да. Даже зная этот паттерн возникают ошибки проектирования. Тем не менее, я все-таки настаиваю, что то, чем я тут (у себя) занимаюсь, используя ножественное наследование на полную катушку, позволяет мне сделать это быстро. Для меня это главное. Второй важной частью является то, что сопровождение такого кода может быть осуществлено просто, а значит дешево. Это за счет того, что я не накручиваю много зависимостей одного от другого через чисто виртуальные интерфейсы. Просто в итоге получается, что каждый кусочек кода работает на одну большую козявку, которая живет и зравствует в любых условиях. Добавление функционала то же производится просто. Короче мне ТАК НРАВИТЬСЯ! Все. закончим.
Здравствуйте, Leshi, Вы писали:
L>Здравствуйте, StanislavK, Вы писали:
SK>>Неправильно мыслишь — к сожалению, заставляют. Я еще не разу в жизни не видел ни одного серьезного проекта написанного одним человеком. И, к сожалению, чем больше возможностей языка, тем больше возможности у людей написать такое чего писать не стоит. L>Значит плохо работают проект-менеджеры. Надо подбирать людей равной квалификации, тогда все будет хорошо.
Ты серьезно так думаешь? Скажи, хоть раз в жизни ты встречаел такую ситуацию, чтобы все было хорошо? Я — нет и не думаю, что когда-нить такое увижу.
Leshi пишет:
> C>А с чего это они должны быть объединены? > Потому что по сути это одно и то же.
Модель, вид и контроллер — это разные сущности.
> C>Читать про паттерн MVC. ОООООЧень многие ошибки проектирования как > раз и > C>возникают из-за незнания этого паттерна. > м-да. Даже зная этот паттерн возникают ошибки проектирования. Тем не > менее, я все-таки настаиваю, что то, чем я тут (у себя) занимаюсь, > используя ножественное наследование на полную катушку, позволяет мне > сделать это *быстро*. Для меня это главное.
Ну так пиши на VB!
> Второй важной частью является то, что сопровождение такого кода может > быть осуществлено *просто*, а значит дешево.
А вот щаз. Оно осуществляется просто, пока помнишь как работает такой
код. Я имел несчастье поддерживать код, в котором MH (причем
виртуальное) использовалось "на полную катушку", закончилось это тем,
что я переписал его в нормальный вид.
> Это за счет того, что я не накручиваю много зависимостей одного от > другого через чисто виртуальные интерфейсы. Просто в итоге получается, > что каждый кусочек кода работает на одну большую козявку, которая > живет и зравствует в любых условиях. Добавление функционала то же > производится просто. Короче мне ТАК НРАВИТЬСЯ! Все. закончим.
Ну так некоторым goto нравятся. А еще другим нравится Fortran и Cobol.
Но это не значит, что ради того нужно делать C# похожими на эти языки.
Здравствуйте, StanislavK, Вы писали:
SK>>>Неправильно мыслишь — к сожалению, заставляют. Я еще не разу в жизни не видел ни одного серьезного проекта написанного одним человеком. И, к сожалению, чем больше возможностей языка, тем больше возможности у людей написать такое чего писать не стоит. L>>Значит плохо работают проект-менеджеры. Надо подбирать людей равной квалификации, тогда все будет хорошо. SK>Ты серьезно так думаешь?
Я в этом полностью уверен. SK>Скажи, хоть раз в жизни ты встречаел такую ситуацию, чтобы все было хорошо? Я — нет и не думаю, что когда-нить такое увижу.
Я то же Но хочеться верить, что встречу. Я несколько более лучшей ситуации, я сам себе коллег выбираю. И квалификацию сам проверяю. И стили программирования проверяю. И не нагружаю людей тем, что им не по зубам. При серьезных трудностях либо коллективное обсуждение/разъяснение, либо изменение задания. Все равно не получается, чтобы все хорошо было но я к этому стремлюсь
Здравствуйте, Cyberax, Вы писали:
C>Модель, вид и контроллер — это разные сущности.
Это все контейнер.
C>Ну так пиши на VB!
С каких пор в VB есть МН?
>> Второй важной частью является то, что сопровождение такого кода может >> быть осуществлено *просто*, а значит дешево.
C>А вот щаз. Оно осуществляется просто, пока помнишь как работает такой C>код. Я имел несчастье поддерживать код, в котором MH (причем C>виртуальное) использовалось "на полную катушку", закончилось это тем, C>что я переписал его в нормальный вид.
Это не говорит о том, что код был плох
C>Ну так некоторым goto нравятся. А еще другим нравится Fortran и Cobol. C>Но это не значит, что ради того нужно делать C# похожими на эти языки.
Давай так: я спросил кто как объодится БЕЗ МНОЖЕСТВЕННОГО НАСЛЕДОВАНИЯ. Я не настаиваю, что мой подход к программированию единственно правильный. Я просто хотел узнать КАК. Выяснил, что единственное работающее решение, на мой взгляд, сделать 39 протезов одноногой сороканожке. Все, спасибо, я все выяснил.
Здравствуйте, Leshi, Вы писали:
L>Здравствуйте, StanislavK, Вы писали:
SK>>Ты серьезно так думаешь? L>Я в этом полностью уверен. SK>>Скажи, хоть раз в жизни ты встречаел такую ситуацию, чтобы все было хорошо? Я — нет и не думаю, что когда-нить такое увижу. L>Я то же Но хочеться верить, что встречу. Я несколько более лучшей ситуации, я сам себе коллег выбираю. И квалификацию сам проверяю. И стили программирования проверяю. И не нагружаю людей тем, что им не по зубам. При серьезных трудностях либо коллективное обсуждение/разъяснение, либо изменение задания. Все равно не получается, чтобы все хорошо было но я к этому стремлюсь
Раз ты тоже, тогда о чем разговор? Чего доказать-то пытаешься? Большинство проектов над которыми я работал были писаны не одной коммандой и десятками людей. Нельзя всех их отфильтровать и проверить, а главное это дорого требует много времени. Хороших разработчиком мало и они уже работают, просто так к тебе не пойдут, а если будешь долго воротить нос, не брать средненьких, то, рискуешь не набрать людей к сроку.
Здравствуйте, Leshi, Вы писали:
СГ>> Классы, от которых производится МН могут иметь свои собственные переменные. И особенно страшно — private переменные, то есть скрытое от класса-потомка состояние которое он сам контролировать не сможет.
L>Что в этом плохого? Если потомку необязательно знать о природе вещей в родителе, то можно и private (правда я сам это не приветствую и еще не разу не применял)
Есть интерфейсы и есть объект эти интерфейсы реализующий. Данные (то есть внутреннее состояние) есть только у объекта. Все бело и пушисто. Однако если interface превратить в DEFINITION, то безина и пушистность не исчезнут, а вкусности множественного наследования мы поимеем.
С другой стороны, если есть множество классов объектов каждый со своим внутренним приватным состоянием и мы пытаемся делать множественное наследование таких классов, то это изврат, ибо в данном случае более подходит композиция/агрегирование/делегирование. В самом деле, ну что это за объект такой получиться, который свое собственное внутреннее состояние полностью не контролирует! Уж сам за себя-то объект должен отвечать?
Здравствуйте, Сергей Губанов, Вы писали:
СГ> Уж сам за себя-то объект должен отвечать?
Я уже привел пример со сторонней библиотекой. И мой ответ: нет, не должен.
Хотя позиция мне понятна.
Здравствуйте, StanislavK, Вы писали:
SK>Раз ты тоже, тогда о чем разговор? Чего доказать-то пытаешься?
Доказать -- ничего. Хотел узнать как МН реализовать без оного. SK>Большинство проектов над которыми я работал были писаны не одной коммандой и десятками людей. Нельзя всех их отфильтровать и проверить, а главное это дорого требует много времени.
Факт. SK>Хороших разработчиком мало
Факт! SK>и они уже работают, просто так к тебе не пойдут, а если будешь долго воротить нос, не брать средненьких, то, рискуешь не набрать людей к сроку.
Сильных разработчиков можно подготовить. Средние и даже слабые то же подойдут. Вопрос в гибкости ума. Если сознание работает по шаблонам -- плохо. Количество шаблонов ограничено.
Hello, Leshi!
You wrote on Thu, 17 Mar 2005 10:38:18 GMT:
S>> На самом деле там усложнение дизайна для поддержки множественного S>> наследования потребовалось бы довольно сильное. Поскольку у всех S>> объектов общий предок, то множественное наследование автоматически S>> превращается в виртуальное. L> Это похоже на проблемы индейцев, которые шерифа, как известно, не L> касаются =)
У "шерифа" проблемы в этом случае тоже должны бы появиться — в виде
повышения прожорливости по памяти. Я, по крайней мере, не вижу, как такую
штуку можно сделать на халяву.
L> Другими словами, просто кишка тонка была сделать множественное L> наследование? Ну похоже.
Я бы так вопрос не ставил Поскольку есть более простые способы решения
проблемы с множественным наследованием.
S>> Которым даже в С++ стараются без острой необходимости не S>> пользоваться. L> Да. Но если острая необходимость возникает, тогда деваться некуда.
Есть куда. Лишней писанины, правда, при этом иногда много будет. Вообще, зря
из С++ делегирование выкинули Тоже, кстати, по просьбам трудящихся,
мотивируя заботой о простоте языка
With best regards, Sergey.
Posted via RSDN NNTP Server 1.9
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, StanislavK, Вы писали:
SK>Ты серьезно так думаешь? Скажи, хоть раз в жизни ты встречаел такую ситуацию, чтобы все было хорошо? Я — нет и не думаю, что когда-нить такое увижу.
Не встречал. И что, выход найден в том, чтоб равняться на худших? Меня больше прельщают иные варианты. Например, очень полезным зверем является оборзеватель кода. Опытный программер, знающий корпоративный стандарт, который бьёт по рукам за криво написанный код.
Leshi пишет:
> C>Модель, вид и контроллер — это разные сущности. > Это все контейнер.
Что такое "контейнер"?
> C>Ну так пиши на VB! > С каких пор в VB есть МН?
Зато там все просто — таскаешь себе мышкой контролы...
> C>А вот щаз. Оно осуществляется просто, пока помнишь как работает такой > C>код. Я имел несчастье поддерживать код, в котором MH (причем > C>виртуальное) использовалось "на полную катушку", закончилось это тем, > C>что я переписал его в нормальный вид. > Это не говорит о том, что код был плох
Код не был плохим. Он просто был неподдериживаемым, было очень сложно
прослеживать зависимости между сущностями.
> C>Ну так некоторым goto нравятся. А еще другим нравится Fortran и Cobol. > C>Но это не значит, что ради того нужно делать C# похожими на эти языки. > Давай так: я спросил кто как объодится БЕЗ МНОЖЕСТВЕННОГО НАСЛЕДОВАНИЯ.
Так ответили же: проектируют так, чтобы MH не было нужно.
Здравствуйте, tarkil, Вы писали:
T>Здравствуйте, StanislavK, Вы писали:
SK>>Ты серьезно так думаешь? Скажи, хоть раз в жизни ты встречаел такую ситуацию, чтобы все было хорошо? Я — нет и не думаю, что когда-нить такое увижу.
T>Не встречал. И что, выход найден в том, чтоб равняться на худших? Меня больше прельщают иные варианты. Например, очень полезным зверем является оборзеватель кода. Опытный программер, знающий корпоративный стандарт, который бьёт по рукам за криво написанный код.
Я не отрицаю, что этим заниматься можно и нужно. Но я не разу не видел проекта, где бы все было хорошо. Да и к тому же, если над проектом работают 10 программеров, опытный программер только и будет заниматься просмотром кода, на работу у него времени не хватит, да и на просмотр, думаю тоже
Надо не равняться на худших, надо делать так, чтобы в худшем случае последствия были наименнее плачевными.
Здравствуйте, Cyberax, Вы писали:
C>Что такое "контейнер"?
Ну началось... Хранилище данных!
>> C>Ну так пиши на VB! >> С каких пор в VB есть МН? C>Зато там все просто — таскаешь себе мышкой контролы...
А мне не надо контролы.
C>Код не был плохим. Он просто был неподдериживаемым, было очень сложно C>прослеживать зависимости между сущностями.
Опять же, не факт, что он был плохо поддерживаемым. Просто надо понимать ка работает МН. А вообще, есть люди, который любой чужой код считают неподдерживаемым.
C>Так ответили же: проектируют так, чтобы MH не было нужно.
Нет, как раз-таки проектирование к кодированию относится так же, как изображение яблока к яблоне. Проектировать надо так, чтобы было хорошо понятно. А уже кодировать надо как позволяет язык. И если проект был с МН, то надо выбирать соответствующие инструменты, а не перепроектировать заново.
Здравствуйте, Leshi, Вы писали:
L>Здравствуйте, Сергей Губанов, Вы писали:
СГ>> Уж сам за себя-то объект должен отвечать? L>Я уже привел пример со сторонней библиотекой. И мой ответ: нет, не должен. L>Хотя позиция мне понятна.
Честно говоря, я что-то не заметил в Вашем примере множественного наследования классов объектов.
Объединение нескольких классов объектов каждый со своим внутренним приватным состоянием в один мега класс есть дефакто и деюро композиция/агрегация. Результирующий объект именно агрегирует все это хозяйство, а то что в С++ это выглядит как один мега класс в данном случае как раз и является "синтаксическим сахаром". interface/definition — не имеют своего внутреннего состояния, это лишь "определения"; внутреннее состояние есть только у самого объекта-имплементатора. Если в definition и описаны переменные, то это переменные этого самого объекта-имплементатора, то есть если одно и тоже definition в списке реализации встречается несколько раз (например несколько других definition были отрефайнены (refine) от него), то это не означает, что объект должен иметь несколько копий таких переменных. В то время как при наследовании от нескольких копий какого-то одного класса объектов имеющих внутреннее приватное и пусть даже не приватное состояние мы сталкиваемся с проблемой — сколько копий переменных внутреннего состояния тех классов объектов должен иметь результирующий объект...
Здравствуйте, StanislavK, Вы писали:
SK>Я не отрицаю, что этим заниматься можно и нужно. Но я не разу не видел проекта, где бы все было хорошо. Да и к тому же, если над проектом работают 10 программеров, опытный программер только и будет заниматься просмотром кода, на работу у него времени не хватит, да и на просмотр, думаю тоже
Просмотр кода — это и есть его работа. Не менее важная, чем написание кода, как такового.
SK>Надо не равняться на худших, надо делать так, чтобы в худшем случае последствия были наименнее плачевными.
Imho, нужен копромисс. Резать полезные возможности только потому, что кто-то на них прокосячит тоже не самая здравая идея. Интерфейсы и композиция это прекрасно, только почему ж я не могу все методы оптом делегировать классу-члену в Java (в Дельфи, кстати, было такое). А должен руками каждый метод объявлять? Недоработка, просто недоработка.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Концептуально, DEFINITION эквивалентна абстрактному С++ классу без переменных, без конструктора, без деструктора, а переменные сэмулированы с помощью абстрактных get/set методов.
Концептуально, эта схема эквивалентна определению интерфейсов в VB6, Java, C#... Ничего нового здесь нет.
СГ>Почему реализация МН в языке С++ вызывает нарекания: СГ> Классы, от которых производится МН могут иметь свои собственные переменные. И особенно страшно — private переменные, то есть скрытое от класса-потомка состояние которое он сам контролировать не сможет.
При одиночном наследовании класс-предок тоже может иметь собственные скрытые переменные. Что в этом страшного-ужасного?
СГ> Классы, от которых производится МН могут иметь конструкторы и деструкторы (в том числе изменяющие скрытое от класса-потомка состояние)
В С++ порядок конструкторов/деструкторов детерминирован, и более того, он такой, что к моменту вызова конструктора/деструктора предка потомок ещё/уже не существует. Следовательно, динамика состояний его никак не волнует. (Конечно, с помощью танца с бубном или кривых рук можно похакать всё что угодно, но это отдельный предмет для разговора).
При чём здесь множественное наследование?
СГ> От класса уже имеющего несколько (множественных) предков можно еще раз (множественно) отнаследоваться. СГ>все это может создать "гремучую смесь", способную если уж и не подорвать целостность системы, то запутать программиста — точно.
Сказки на ночь. Придёт чОрный деструктор, подорвёт цЭлостность и запутает (запугает) программиста.
Здравствуйте, Сергей Губанов, Вы писали:
СГ> Классы, от которых производится МН могут иметь свои собственные переменные. И особенно страшно — private переменные, то есть скрытое от класса-потомка состояние которое он сам контролировать не сможет.
А разве private атрибуты в одиночном наследовании не скрывают от класса-потомка состояние? Может private-атрибуты вообще выбросить? А за ними и private-наследование?
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, tarkil, Вы писали:
T>Здравствуйте, StanislavK, Вы писали:
SK>>Я не отрицаю, что этим заниматься можно и нужно. Но я не разу не видел проекта, где бы все было хорошо. Да и к тому же, если над проектом работают 10 программеров, опытный программер только и будет заниматься просмотром кода, на работу у него времени не хватит, да и на просмотр, думаю тоже T>Просмотр кода — это и есть его работа. Не менее важная, чем написание кода, как такового.
Боюсь, что убедить заказчика в таком решении будет не просто, а так же директора, т.к. платить такому человеку надо начиная от $1500. Встает вопрос о том, насколько это окупится. Есть множество проектов, где лучше взять 2 студней за 600 баксов каждый, чем одного серьезного дядьку. Так и поступают — будет студней.
Да и к тому же, ты бы согласился этим заниматься?
Что хорошо, а что плохо — знаю все, но действовать часто приходится совсем не так как хотелось бы.
SK>>Надо не равняться на худших, надо делать так, чтобы в худшем случае последствия были наименнее плачевными.
T>Imho, нужен копромисс. Резать полезные возможности только потому, что кто-то на них прокосячит тоже не самая здравая идея. Интерфейсы и композиция это прекрасно, только почему ж я не могу все методы оптом делегировать классу-члену в Java (в Дельфи, кстати, было такое). А должен руками каждый метод объявлять? Недоработка, просто недоработка.
Сделай один метод, который возвращает того, кому собираешься делигировать, это не сложно.
Здравствуйте, eao197, Вы писали:
E>А разве private атрибуты в одиночном наследовании не скрывают от класса-потомка состояние? Может private-атрибуты вообще выбросить? А за ними и private-наследование?
Естественно! Например, в оберонах инкапсуляция осуществляется на уровне модуля, а не отдельного класса. А межмодульное наследование классов, вообще-то, не сильно-то поощряется ибо противоречит КОП.
И как весь MVC относится к хранилищу данных? Тут к хранилищу данным
только буква 'M' отношение может иметь.
> C>Код не был плохим. Он просто был неподдериживаемым, было очень сложно > C>прослеживать зависимости между сущностями. > Опять же, не факт, что он был плохо поддерживаемым. Просто надо > понимать ка работает МН.
MH _увеличивает_ число зависимостей. Каждый базовый класс влияет на
поведение каждого — получается квадратичная зависимость. При 10 базовых
классов их взаимоотношения уже в голове удержать сложно.
Заменяя наследование аггрегированием мы уменьшаем число зависимостей, и
делаем их более явными.
> C>Так ответили же: проектируют так, чтобы MH не было нужно. > Нет, как раз-таки проектирование к кодированию относится так же, как > изображение яблока к яблоне. Проектировать надо так, чтобы было хорошо > понятно. А уже кодировать надо как позволяет язык. И если проект был с > МН, то надо выбирать соответствующие инструменты, а не > перепроектировать заново.
Вообще-то, прежде чем брать IDE и кидаться в бой ("кодирование")
нормальные программисты сначала думают ЧТО они будут писать (проектируют).
Здравствуйте, Кодт, Вы писали:
К>При одиночном наследовании класс-предок тоже может иметь собственные скрытые переменные. Что в этом страшного-ужасного?
Страшное ужасное: объект не отвечает за свое собственное состояние, ибо часть этого состояния от него самого скрыта, по сути этот объект просто агрегирует в себе какой-то другой объект.
Во-первых, в случае одиночного наследования, по крайней мере не возникает проблем с количеством копий таких скрытых данных в том случае если множественно отнаследовались от "двух экземпляров одного и того же класса".
Во-вторых, сейчас даже от одиночного наследования скрытого состояния классов объектов уже отказываются. Например, в Active Oberon и Zonnon от OBJECT уже отнаследоваться нельзя ни множественно ни одиночно:
OBJECT является носителем состояния и реализовывает несколько DEFINITION каждое из которых уже может иметь реализацию по умолчанию — вот оно множественное наследование, но от OBJECT уже отнаследоваться нельзя.
Сергей Губанов пишет:
> >DEFINITION--->---DEFINITION---+ > | > DEFINITION----->-----+---->---OBJECT > | > DEFINITION-------->----+ > > > OBJECT является носителем состояния и реализовывает несколько > DEFINITION каждое из которых уже может иметь реализацию по умолчанию — > вот оно множественное наследование, но от OBJECT уже отнаследоваться > нельзя.
Отвечу только на первый вопрос, потому что по остальным уже договорились до верблюдов.
>> C>Что такое "контейнер"? >> Ну началось... Хранилище данных! C>И как весь MVC относится к хранилищу данных? Тут к хранилищу данным C>только буква 'M' отношение может иметь.
Я имел в виду, что все предки в моем проекте это контейнеры. И я рассматривал только контейнер. Представления (вид) у меня как раз-таки простые.
Здравствуйте, Сергей Губанов, Вы писали:
К>>При одиночном наследовании класс-предок тоже может иметь собственные скрытые переменные. Что в этом страшного-ужасного?
СГ>Страшное ужасное: объект не отвечает за свое собственное состояние, ибо часть этого состояния от него самого скрыта, по сути этот объект просто агрегирует в себе какой-то другой объект.
Объект, тем самым, делегирует часть функциональности своему предку.
СГ>Во-первых, в случае одиночного наследования, по крайней мере не возникает проблем с количеством копий таких скрытых данных в том случае если множественно отнаследовались от "двух экземпляров одного и того же класса".
Ну а если я вместо МН просто в каждом из предков (длинная цепь наследования) размещу член-данное одного и того же типа и с одним и тем же именем? Тоже будет много копий, к которым неквалифицированный доступ (просто по имени) будет осложнён.
Если язык (С++) выполняет сокрытие имён, то доступ будет к самому ближнему члену. Если нет — будет неоднозначность.
В случае МН неквалифицированный доступ к однотипным предкам неоднозначный и не может быть разрешён автоматически. Компилятор надаёт по пальцам и заставит написать путь к тому из них, который действительно нужен.
Либо — делаем виртуальное наследование и наслаждаемся. В любом случае это обязанность программиста — сперва думать, затем делать.
СГ>Во-вторых, сейчас даже от одиночного наследования скрытого состояния классов объектов уже отказываются. Например, в Active Oberon и Zonnon от OBJECT уже отнаследоваться нельзя ни множественно ни одиночно:
Ну или например VB6. Там вместо наследования классов делается великий копи-паст (либо делегирование — копипаст объявлений членов, либо агрегирование).
Здравствуйте, Leshi, Вы писали:
L>Поясню почему. Во-первых, сласс отображающий дерево я использую не только в одном проекте (да и не в однм месте), поэтому менять его под конкреные нужды не хочется. Во-вторых, сохранение и загрузка из БД при отображении не играет никакой роли, главное понять что отображать надо. В результате создаем производную ноду в виде L>
class MyNode: public TreeNode, public StoreNode
L>и переопределяем виртуальные методы tnGetTitle(), tnGetImage(), tnSetTitle(). Все готово, остальной функционал уже реализован. Через интерфейсы пришлось бы давольно много методов определять для UI и БД.
Здравствуйте, Cyberax, Вы писали:
C>Это неправильно. Таже TreeNode не должна наследоваться от StoreNode, а C>должна ее аггрегировать. Посмотри как это сделано в Swing — весьма C>элегантно и красиво.
Я даже больше скажу — по хорошему она и агрегировать не должна. Выстраивание иерархических цепочек в памяти конечно первое что приходит на ум, но далеко не всегда оптимальное.
В свинге, кстати, (ты о JTree речь ведешь?) тоже никакой агрегации. Для тех кто не знает, приведу код из него (комментарии я сократил):
package javax.swing.tree;
import javax.swing.event.*;
/**
* The interface that defines a suitable data model for a <code>JTree</code>.
*/
public interface TreeModel
{
/**
* Returns the root of the tree. Returns <code>null</code>
* only if the tree has no nodes.
*
* @return the root of the tree
*/
public Object getRoot();
/**
* Returns the child of <code>parent</code> at index <code>index</code>
* in the parent's
* child array. <code>parent</code> must be a node previously obtained
* from this data source. This should not return <code>null</code>
* if <code>index</code>
* is a valid index for <code>parent</code> (that is <code>index >= 0 &&
* index < getChildCount(parent</code>)).
*
* @param parent a node in the tree, obtained from this data source
* @return the child of <code>parent</code> at index <code>index</code>
*/
public Object getChild(Object parent, int index);
/**
* Returns the number of children of <code>parent</code>.
* Returns 0 if the node
* is a leaf or if it has no children. <code>parent</code> must be a node
* previously obtained from this data source.
*
* @param parent a node in the tree, obtained from this data source
* @return the number of children of the node <code>parent</code>
*/
public int getChildCount(Object parent);
/**
* Returns <code>true</code> if <code>node</code> is a leaf.
* It is possible for this method to return <code>false</code>
* even if <code>node</code> has no children.
* A directory in a filesystem, for example,
* may contain no files; the node representing
* the directory is not a leaf, but it also has no children.
*
* @param node a node in the tree, obtained from this data source
* @return true if <code>node</code> is a leaf
*/
public boolean isLeaf(Object node);
/**
* Messaged when the user has altered the value for the item identified
* by <code>path</code> to <code>newValue</code>.
* If <code>newValue</code> signifies a truly new value
* the model should post a <code>treeNodesChanged</code> event.
*
* @param path path to the node that the user has altered
* @param newValue the new value from the TreeCellEditor
*/
public void valueForPathChanged(TreePath path, Object newValue);
/**
* Returns the index of child in parent. If either <code>parent</code>
* or <code>child</code> is <code>null</code>, returns -1.
* If either <code>parent</code> or <code>child</code> don't
* belong to this tree model, returns -1.
*
* @param parent a note in the tree, obtained from this data source
* @param child the node we are interested in
* @return the index of the child in the parent, or -1 if either
* <code>child</code> or <code>parent</code> are <code>null</code>
* or don't belong to this tree model
*/
public int getIndexOfChild(Object parent, Object child);
//
// Change Events
//
/**
* Adds a listener for the <code>TreeModelEvent</code>
* posted after the tree changes.
*
* @param l the listener to add
* @see #removeTreeModelListener
*/
void addTreeModelListener(TreeModelListener l);
/**
* Removes a listener previously added with
* <code>addTreeModelListener</code>.
*
* @see #addTreeModelListener
* @param l the listener to remove
*/
void removeTreeModelListener(TreeModelListener l);
Здравствуйте, Cyberax, Вы писали:
C>Поздравляю. Зоннон дошел до понятия интерфейсов.
Спасибо. Но только он не просто дошел, а уже и перешел... ведь DEFINITION по сравнению с interface еще может содержать описание переменных, а также методы с заданной реализацией по умолчанию. То есть DEFINITION ближе к abstract class чем к interface.
Здравствуйте, Leshi, Вы писали:
AVK>>Паттерн Bridge спасет отца русской демократии L>Позволит выкрутиться, а не спасет. Уже обсудили.
Странный у тебя подход. Это "выкрутится" на порядок более грамотное решение, чем то что ты привел. Именно вариант когда все пихается в одно дерево это выкручивание ради того чтобы съэкономить на проектированиию Применяя такое решение остается только надеятся на авось, что не понадобится, к примеру, прикручивать сохранение еще куда нибудь, да так чтобы это мог сделать другой программист.
Сергей Губанов пишет:
> C>Поздравляю. Зоннон дошел до понятия интерфейсов. > Спасибо. Но только он не просто дошел, а уже и перешел... ведь > *DEFINITION* по сравнению с *interface* еще может содержать описание > переменных
Фигня, просто скрывают аксессоры.
> а также методы с заданной реализацией по умолчанию. То есть > *DEFINITION* ближе к *abstract class* чем к *interface*.
Здравствуйте, AndrewVK, Вы писали:
AVK>Применяя такое решение остается только надеятся на авось, что не понадобится, к примеру, прикручивать сохранение еще куда нибудь, да так чтобы это мог сделать другой программист.
Как раз ради того, чтобы сохранение еще куда-нибудь можно было прикрутить не сильно затрагивая основной код (добавляем еще одного родителя) все это и делалось. А сможет другой программист прикрутить его или нет это, имхо, вопрос документирования.
Сейчас оно успешно сохраняется в БД, локально на диске в виде иерархии файов и директорий. В ближайших планах сохранение на веб через HTTP. Просто если все расписывать, то будут мемуары, заслуживающие отдельного сайта, а не ветки форума. И переплетений там больше чем два. И множественное наследование там самы быстрый способ все это закодировать. А Bridge предполагает дополнительной писанины тысяч на двадцать строк.
Спасибо, что подсказали вариант как можно обойтись без множественного наследования, очень полезно. Правда это я и так знал, надеялся, что существует что-то более похожее на множественное наследование, кроме копи-пасте или переопределения множества методов интерфейсов. Но для моего проекта это нецелесообразно.
Здравствуйте, Cyberax, Вы писали:
C>Фигня, просто скрывают аксессоры. C>Тоже фигня — синтаксический сахар.
"Все фигня, кроме мохнатых пчел.
Да и они фигня, если их побрить" (с) Народная мудрость.
Здравствуйте, Leshi, Вы писали:
AVK>>Применяя такое решение остается только надеятся на авось, что не понадобится, к примеру, прикручивать сохранение еще куда нибудь, да так чтобы это мог сделать другой программист. L>Как раз ради того, чтобы сохранение еще куда-нибудь можно было прикрутить не сильно затрагивая основной код (добавляем еще одного родителя) все это и делалось.
Здорово — добавление предка к классу называется не затарагивать основной код? Вобщем на редкость неудачное решение.
L> А сможет другой программист прикрутить его или нет это, имхо, вопрос документирования.
Далеко не только.
L>Сейчас оно успешно сохраняется в БД, локально на диске в виде иерархии файов и директорий. В ближайших планах сохранение на веб через HTTP. Просто если все расписывать, то будут мемуары, заслуживающие отдельного сайта, а не ветки форума. И переплетений там больше чем два. И множественное наследование там самы быстрый способ все это закодировать. А Bridge предполагает дополнительной писанины тысяч на двадцать строк.
Ничуть. Bridge позволяет получить действительно хорошую изоляцию структуры с данными (модели) от алгоритмов ее обработки. Называть классические паттерны GoF выкручиванием несколько самонадеянно, не находишь?
L>Спасибо, что подсказали вариант как можно обойтись без множественного наследования, очень полезно.
Ты видимо меня не понял — я привел пример не того как можно обойтись без МН, а того как надо правильно решать задачу. В том числе и на языках с МН.
L> Правда это я и так знал, надеялся, что существует что-то более похожее на множественное наследование, кроме копи-пасте или переопределения множества методов интерфейсов.
Т.е. по твоему bridge это копи-пасте и переопределение множества методов интерфейсов? Ты уверен что хорошо себе представляешь что такое bridge? http://en.wikipedia.org/wiki/Bridge_pattern
The bridge design pattern is meant to "decouple an abstraction from its implementation so that the two can vary independently" (Gamma et. al.).
...
Say you have an abstraction, shapes. You want to have many types of shapes and each with its own properties but there are things that all shapes do. One thing you want all shapes to do is draw themselves. However, drawing graphics to a screen can sometimes be dependent on different graphics implementations or operating systems. You want your shapes to be able to be drawn on many types of systems but having the shape itself implement them all or modifying the shape class to work with different architechtures. The bridge helps by allowing you to create new classes that provide the drawing implementation. The, abstraction, shape class provides methods for getting the size or properties of a shape while the, implementation, drawing class provides an interface for drawing graphics. Now if a new shape needs to be created or you want to draw your shapes on a new graphics API then it is very easy to add a new class that implements the features you need.
А то, о чем ты видимо подумал, называется delegation. В той задаче, что обсуждалась, будет полезно еще поглядеть на паттерны hierarchical visitor(http://c2.com/cgi/wiki?HierarchicalVisitorPattern), mediator, strategy(http://en.wikipedia.org/wiki/Strategy_pattern). В частности, последний позволит тебе обойтись без так ненравящегося тебе delegation pattern, заодно повысив управляемость исходного кода.
Leshi пишет:
> C>И как весь MVC относится к хранилищу данных? Тут к хранилищу данным > C>только буква 'M' отношение может иметь. > Я имел в виду, что все предки в моем проекте это контейнеры. И я > рассматривал только контейнер. Представления (вид) у меня как раз-таки > простые.
Самое прикольное, что ни разу в жизни не использовал множественное наследование. Только используя чужие библиотеки, или по требованию чужих библиотек. Что я делаю неправильно?
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Почему реализация МН в языке С++ вызывает нарекания: СГ> Классы, от которых производится МН могут иметь свои собственные переменные. И особенно страшно — private переменные, то есть скрытое от класса-потомка состояние которое он сам контролировать не сможет.
Почему это не может? Очень даже может — через интерфейс, предоставляемый предком.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Это почему не компонентная? Как по мне, то реализация вполне нормальная.
Это только по тебе, так как ты не задумался как следует. А если бы задумался бы, то понял бы, что в рамках компонентной модели дотнета или Явы такая модель приведет к зависимости от компиляции. Если поместить базовые классы в разные сборки, то добавление нового члена или изменение публичного интерфейса приведет к необходимости перекомпиляции сборки содержащей наследника. Сейчас же это не обязательно.
... << RSDN@Home 1.1.4 beta 4 rev. 359>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, StanislavK, Вы писали:
SK>Боюсь, что убедить заказчика в таком решении будет не просто, а так же директора, т.к. платить такому человеку надо начиная от $1500. Встает вопрос о том, насколько это окупится. Есть множество проектов, где лучше взять 2 студней за 600 баксов каждый, чем одного серьезного дядьку. Так и поступают — будет студней.
Да, к сожалению. Многих пока ещё не удалось убедить, что написание кода это едва ли не самая маленькая часть работы. Что уж говорить о признании необходимости таких лишних людей и понятий как тестеры, корпоративный стандарт на код, спецы по работе с юзерами, система контроля версий...
SK>Да и к тому же, ты бы согласился этим заниматься?
Конечно. Если не только проверять код, но и участвовать в написании этих требований. Для меня это интересная работа.
SK>Сделай один метод, который возвращает того, кому собираешься делигировать, это не сложно.
Sure. Только класс не будет считаться поддерживающим интерфейс. Это, кстати, один из вопросов, который меня живо интересует: а создаёт ли это на практике проблемы, если вместо
class C: implements TreeNode, implements DbNode
{
// простите, если напутал в синтаксисе, Жабу почти не знаюprivate TreeNodeImpl tni;
private DbNodeImpl dni;
public void TreeNodeM1()
{ tni.TreeNodeM1(); }
// и пр. методы интерфейсов аналогичные переходники имеют
};
писать
class C
{
private TreeNodeImpl tni;
private DbNodeImpl dni;
public TreeNode asTreeNode()
{ return tni; }
public DbNode asDbNode()
{ return dni; }
};
Здравствуйте, StanislavK, Вы писали: SK>Боюсь, что убедить заказчика в таком решении будет не просто, а так же директора, т.к. платить такому человеку надо начиная от $1500.
Это верно. SK>Встает вопрос о том, насколько это окупится.
Как правило, окупится. SK>Есть множество проектов, где лучше взять 2 студней за 600 баксов каждый, чем одного серьезного дядьку.
Ну... имхо, таких проектов очень мало. Пока что вся практика убеждает меня в том, что стоимость разработчика растет далеко не в линейной прогрессии от его квалификации. И взять одного за 1500 гораздо выгоднее, чем двух студней. Потому, что он сделает экспорт в экзотический формат за день и еще день отладки, а студни потратят неделю — один на рисование диалога, другой на вывод данных. И потом месяцев шесть придется регулярно оказывать поддержку, исправляя всякие косяки — типа тут не проверили на !=null, там зачем-то привели к байту вместо инта... SK>Так и поступают — будет студней.
Именно. Я даже знаю вид бизнеса, где это выгодно. Когда заказчику продаются человекочасы, конечно выгоднее экспортировать двух студней. Потому как они вдвоем потратят 5X часов вместо X, а внутренний рейт у них в полторашку ниже, чем у гуру. Объем продаж растет, растут проценты менеджера. Все щасливы, включая студентов.
К сожалению, эта модель часто переносится в другие проекты. Некомпетентность руководства, ничего не попишешь.
Посмотрите, как много на форумах сложных вопросов! Человек не умеет функцию из DLL вызвать, а ему надо срочно драйвер ядра написать.
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, StanislavK, Вы писали:
SK>Здравствуйте, Leshi, Вы писали:
L>>Здравствуйте, StanislavK, Вы писали:
L>>Значит плохо работают проект-менеджеры. Надо подбирать людей равной квалификации, тогда все будет хорошо. SK>Ты серьезно так думаешь? Скажи, хоть раз в жизни ты встречаел такую ситуацию, чтобы все было хорошо? Я — нет и не думаю, что когда-нить такое увижу.
Если уж закатились в эту сторону, работа проект-менеджера по-максимуму использовать квалификацию тех людей, которые есть,
а не подбирать и сравнивать.
Здравствуйте, prVovik, Вы писали:
V>Почему это не может? Очень даже может — через интерфейс, предоставляемый предком.
В таком случае это по сути является агрегированием другого объекта взаимодействие с которым осуществляется по предоставляемому им интерфейсу. "Наследование данных" всегда по своей сути является их агрегацией.
Здравствуйте, Cyberax, Вы писали:
C>Которое является просто синтаксическим сахаром над интерфейсами. Ни C>Java, ни .NET не запрещают использовать множественное наследование, они C>лишь запрещают множественное наследование классов на уровне CLI. C>Множественно наследование на уровне прикладного языка замечательно C>выражается с помощью интерфейсов.
C>Для примера: http://kiev.forestro.com/kiev-body.html — в нем MH было в C>97 году. Язык компилируется в Java bytecode.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>В таком случае это по сути является агрегированием другого объекта взаимодействие с которым осуществляется по предоставляемому им интерфейсу. "Наследование данных" всегда по своей сути является их агрегацией.
Основная функция механизма наследования — это определение подтипов.
Причем определение подтипа — это отнюдь не повод нарушать инкапсуляцию.
Здравствуйте, prVovik, Вы писали:
V>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>В таком случае это по сути является агрегированием другого объекта взаимодействие с которым осуществляется по предоставляемому им интерфейсу. "Наследование данных" всегда по своей сути является их агрегацией.
V>Основная функция механизма наследования — это определение подтипов. V>Причем определение подтипа — это отнюдь не повод нарушать инкапсуляцию.
aefimov пишет:
> C>Которое является просто синтаксическим сахаром над интерфейсами. Ни > C>Java, ни .NET не запрещают использовать множественное наследование, они > C>лишь запрещают множественное наследование классов на уровне CLI. > C>Множественно наследование на уровне прикладного языка замечательно > C>выражается с помощью интерфейсов. > C>Для примера: http://kiev.forestro.com/kiev-body.html — в нем MH было в > C>97 году. Язык компилируется в Java bytecode. > На уровне байткода JVM есть понятие объектов?
Естественно Например байт-коды типа invokevirtual как-бы предполагают
наличие объектов.
Здравствуйте, Сергей Губанов, Вы писали:
V>>Почему это не может? Очень даже может — через интерфейс, предоставляемый предком.
СГ>В таком случае это по сути является агрегированием другого объекта взаимодействие с которым осуществляется по предоставляемому им интерфейсу. "Наследование данных" всегда по своей сути является их агрегацией.
Невозможно свести наследование к агрегации. Наследник может поменять поведение подобъекта-предка, перекрыв виртуальные методы.
То же самое можно сделать, сочетая агрегацию с делегированием — при этом, во-первых, требуется определённая поддержка таких возможностей классом-агрегатом, а во-вторых, много писанины в финальном классе.
Здравствуйте, Сергей Губанов, Вы писали:
V>>Основная функция механизма наследования — это определение подтипов. V>>Причем определение подтипа — это отнюдь не повод нарушать инкапсуляцию.
СГ>Совершенно верно. СГ>И что?..
То, что для обеспечения инкапсуляции надо ограничивать доступ.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, eao197, Вы писали:
E>>А разве private атрибуты в одиночном наследовании не скрывают от класса-потомка состояние? Может private-атрибуты вообще выбросить? А за ними и private-наследование?
СГ>Естественно! Например, в оберонах инкапсуляция осуществляется на уровне модуля, а не отдельного класса. А межмодульное наследование классов, вообще-то, не сильно-то поощряется ибо противоречит КОП.
А я вот не понимаю, что плохого в том, что базовый класс имеет private-атрибуты. Если он дает public или protected интерфейс для работы с ними, то вообще проблем нет. А если нет интерфейса, значит так и было задумано, чтобы атрибуту не присваивали те значения, которые он не должен иметь.
К тому же, если ты наследуешься от базового класса и используешь его функциональность, значит ты ему доверяешь. В противном случае напиши все сам, какие проблемы-то?
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, WFrag, Вы писали:
WF>Как я обхожусь в Java: куча мелких компонентиков и Spring, их связывающий. Соответственно, вместо сильной зависимости наследование активно используется более слабая — композиция.
Сейчас под .NET использую Spring.NET в основном в качестве сервис-локатора, но постепенно начинаю использовать его более полноценно. Поделитесь практиками использования в Java (насколько полно используете в своих приложениях)
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, Сергей Губанов, Вы писали:
V>>>Почему это не может? Очень даже может — через интерфейс, предоставляемый предком.
СГ>>В таком случае это по сути является агрегированием другого объекта взаимодействие с которым осуществляется по предоставляемому им интерфейсу. "Наследование данных" всегда по своей сути является их агрегацией.
К>Невозможно свести наследование к агрегации. Наследник может поменять поведение подобъекта-предка, перекрыв виртуальные методы.
Речь шла о наследовании данных, а не методов. Данные всегда находятся внутри объекта, то есть агрегируются им. Это на столько тривиально, что даже можно обозвать тавтологией. В Active Oberon и в Zonnon мы имеем DEFINITION у которых своих собственных данных нет, они лишь декларированы. А вот OBJECT-имплементатор этих DEFINITION-ов должен определить (get/set) внутри себя данные продекларированные в DEFINITION-ах. Носителем данных является OBJECT, но OBJECT-ы уже не наследуются друг от друга, т.е. наследования данных там нет.
Здравствуйте, eao197, Вы писали:
E>А я вот не понимаю, что плохого в том, что базовый класс имеет private-атрибуты
1) В случае множественного наследования возникает вопрос сколько копий private-членов будет если среди предков такой класс встречается больше одного раза.
2) В случае одиночного наследования:
Если предок есть абстрактный класс — никаких проблем нет, быть может кроме той что размер объекта теперь скрытым образом входит в определение класса. Так что нечаянно изменив его можно нарваться на неприятности — полную перекомпиляцию всех програм во всем мире в которых использованы классы потомки.
Если предок есть обычный (не абстрактный) класс объекты которого вполне могут существовать самостоятельно, то логичнее использовать композицию объектов получая при этом все преимущества классических паттернов проектирования описанных в GoF. В частности, если в абстрактные классы изменения практически ни когда не вносятся, то в не абстрактные классы, изменения обычно все-таки вносятся (по мере эволюционирования системы). И если от них кто-то имел неосторожность отнаследоваться, то он должен перекомпилироваться, а целостность системы должна быть заново проверена. В случае же композиции объектов перекомпиляция и проверка целостности всей системы не требуется если не изменен внешний интерфейс.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, eao197, Вы писали:
E>>А я вот не понимаю, что плохого в том, что базовый класс имеет private-атрибуты
СГ>1) В случае множественного наследования возникает вопрос сколько копий private-членов будет если среди предков такой класс встречается больше одного раза.
Если говорить про C++ -- то столько, сколько раз базовый класс был невиртуальным базовым классом.
СГ>2) В случае одиночного наследования:
СГ> Если предок есть абстрактный класс — никаких проблем нет, быть может кроме той что размер объекта теперь скрытым образом входит в определение класса. Так что нечаянно изменив его можно нарваться на неприятности — полную перекомпиляцию всех програм во всем мире в которых использованы классы потомки.
Откуда такой глобализм? Имхо, к моему вопросу это имеет какое-то отдаленное отношение.
Скажем беру я библиотеку ACE версии 5.4.3. В ней класс ACE_IPC_SAP содержит private атрибут handle_. От этого класса, например, унаследованы все ACE-вские сокеты. И мне дела нет, что я не могу, унаследуясь от ACE_SOCK_IO, воздействовать напрямую на ACE_IPC_SAP::handle_. И пусть в ACE 5.5 из класса ACE_IPC_SAP этот атрибут перенесут в какой-то другой класс, в тот же ACE_SOCK, скажем. Ну перекомпилирую я свои программы при переходе на ACE 5.5. И что? Я и так по нескольку раз в неделю полную перекомпиляцию проектов делаю.
Ну все, кто будет переходить на ACE 5.5 будут перекомпилировать программы. И что?
СГ> Если предок есть обычный (не абстрактный) класс объекты которого вполне могут существовать самостоятельно, то логичнее использовать композицию объектов получая при этом все преимущества классических паттернов проектирования описанных в GoF. В частности, если в абстрактные классы изменения практически ни когда не вносятся, то в не абстрактные классы, изменения обычно все-таки вносятся (по мере эволюционирования системы). И если от них кто-то имел неосторожность отнаследоваться, то он должен перекомпилироваться, а целостность системы должна быть заново проверена. В случае же композиции объектов перекомпиляция и проверка целостности всей системы не требуется если не изменен внешний интерфейс.
Патерны здесь еще откуда-то взялись...
Простой пример: есть класс File, который содержит private атрибут -- дескриптор открытого файла. Доступ к этому дескриптору либо не предоставляется вообще (работа с файлом идет через protected методы write, read, open, close, seek, tell), либо через какой-то метод типа get_handle(). Что в этом плохого?
Более того, это делает для нас лишний слой абстракции. Допустим на одной платформе File общается с ОС через дескрипторы файлов, на другой через FILE *, на третьей вообще через int 21. А нам до этого дела нет.
Зато мы можем унаследоваться от File и, например, перекрыть его виртуальные методы, чтобы записывать данные не в двоичном raw-формате, а в base64.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>>>В таком случае это по сути является агрегированием другого объекта взаимодействие с которым осуществляется по предоставляемому им интерфейсу. "Наследование данных" всегда по своей сути является их агрегацией.
К>>Невозможно свести наследование к агрегации. Наследник может поменять поведение подобъекта-предка, перекрыв виртуальные методы.
СГ>Речь шла о наследовании данных, а не методов. Данные всегда находятся внутри объекта, то есть агрегируются им. Это на столько тривиально, что даже можно обозвать тавтологией. В Active Oberon и в Zonnon мы имеем DEFINITION у которых своих собственных данных нет, они лишь декларированы. А вот OBJECT-имплементатор этих DEFINITION-ов должен определить (get/set) внутри себя данные продекларированные в DEFINITION-ах. Носителем данных является OBJECT, но OBJECT-ы уже не наследуются друг от друга, т.е. наследования данных там нет.
Во-вторых.
Пропаганда Zonnon — это, конечно, здорово, но все эти фичи уже давным-давно известны: см. например OLE и VB5 (если не раньше; увы, я не помню всю историю вижуал-бейсиков).
Во-первых.
Наследование от класса с состоянием (т.е. содержащего члены-данные). Да, это состояние агрегируется. Но поведение меняется, хотя бы потому, что база может держать виртуальные методы доступа, предназначенные для перекрытия в потомке.
В нулевых.
У меня складывается впечатление, что есть какой-то глубокий изъян в методологии изучения и практики программирования. В основном он присущ изучению структурно-ориентированных языков. Вот что это за изьян: Мышление об объектах как о россыпи деталей (члены структуры, узлы графа, отдельные указатели и т.д.).
Отсюда — написание функций, работающих со списком через указатель на головной узел; динамические массивы на уровне языка, управление которыми (перевыделение памяти, например) доступно кому попало; вот ещё добавляется боязнь скрытого состояния базовых объектов.
VladD2 пишет: > ANS>Это почему не компонентная? Как по мне, то реализация вполне нормальная. > > Это только по тебе, так как ты не задумался как следует. А если бы > задумался бы, то понял бы, что в рамках компонентной модели дотнета или > Явы такая модель приведет к зависимости от компиляции. Если поместить > базовые классы в разные сборки, то добавление нового члена или изменение > публичного интерфейса приведет к необходимости перекомпиляции сборки > содержащей наследника. Сейчас же это не обязательно.
Это уж извините. Эмуляция редко полностью соответсвует своему прототипу.
ЗЫ. Как тут предлагают, такие классы нужно сделать sealed и объявить это
фичей.
--
Andrei N.Sobchuck
JabberID: andreis@jabber.ru. ICQ UIN: 46466235.
Здравствуйте, PeterZT, Вы писали:
PZT>Сейчас под .NET использую Spring.NET в основном в качестве сервис-локатора, но постепенно начинаю использовать его более полноценно. Поделитесь практиками использования в Java (насколько полно используете в своих приложениях)
Да я не то чтобы очень сильно его использовал. Единственное, что могу сказать — как-то сама собой получилась следующая картина: куча мелких компонентиков, каждый с очень простой функциональностью, которые связываются Spring-ом.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, eao197, Вы писали:
E>>Зато мы можем унаследоваться от File
СГ>Не надо. File самодостаточный объект. А чтение/запись идет через вспомогательные объекты: СГ>
СГ>Reader reader = File.NewReader();
СГ>Writer writer = File.NewWriter();
СГ>Scanner scanner = new Scanner(reader);
СГ>Formatter formatter = new Formatter(writer);
СГ>
Ну ты крут! Этож вся библия нафиг ((С) Игорь Угольников).
А у Formatter-ов своих атрибутов не будет? Как же Formatter будет про своего writter-а знать? И имеют ли право потомки Formatter-а изменять writter-а во время работы? Или иерархию Formatter-ов вообще делать не нужно?
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
LuciferMoscow,
> LM>> Здравствуйте, Leshi, можешь привести пример, где не обойтись без множественного наследования? Наиболее реальный
> L> Я могу привести пример, где множественное наследование будет самым элегантным способом.
> Я этого и хочу
Можешь посмотреть на иерархию std::iostream, std::istream, std::ostream из стандартной библиотеки C++. Что такое "самый элегантный способ" можно спорить долго, но то, что множественное наследование в случае std::iostream применено по делу, по-моему, должно быть очевидно.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Это уж извините. Эмуляция редко полностью соответсвует своему прототипу.
А чё мне извинять? Я просто заметил, что решение не совсем хорошее.
ANS>ЗЫ. Как тут предлагают, такие классы нужно сделать sealed и объявить это ANS>фичей.
Давай уж оставим эту фичу для применения по назначению.
... << RSDN@Home 1.1.4 beta 4 rev. 359>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>Тоже фигня — синтаксический сахар.
Ну, да. А for/while синтаксический сахар скрывающий ассемблерные команды.
Синтаксический сахор облегчающий жизнь — это не фигня.
Что до DEFINITION, то по-моему — это неудачный варинт traits/mix-in-ов. Самое простое и логичное что я видел — это когда вводится специальный "тип класса" — trait. Его можно наследовать, но к нему нельзя привести. Таким образом содержимое trait-ов просто копируется в класс. Классы при этом могут иметь одиночное наследование. Причем и trait. Таким образом trait-ы позволяют подключать реализацию (как просто методов, так и интерфейсов).
За счет того, что сделать привидение к trait-у нельзя нет никаких проблем МН, а все пиемущества есть. Думаю Шарпу и Яве такой синтаксический сахар очень не помешал бы.
... << RSDN@Home 1.1.4 beta 4 rev. 359>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>А разве private атрибуты в одиночном наследовании не скрывают от класса-потомка состояние? Может private-атрибуты вообще выбросить? А за ними и private-наследование?
Private-наследование уже выброшено. И, кстати, подилом. Дурь это.
... << RSDN@Home 1.1.4 beta 4 rev. 359>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>А межмодульное наследование классов, вообще-то, не сильно-то поощряется ибо противоречит КОП.
Бред. Это может проиворечить только кривым реализациям. Как, по-твоему, создавать разные библиотечные классы если раследоваться от классов в других модулях нельзя, а библиотека по опредлению другой модуль.
... << RSDN@Home 1.1.4 beta 4 rev. 359>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, eao197, Вы писали:
E>>А разве private атрибуты в одиночном наследовании не скрывают от класса-потомка состояние? Может private-атрибуты вообще выбросить? А за ними и private-наследование?
VD>Private-наследование уже выброшено. И, кстати, подилом. Дурь это.
Из C++ выброшено?
А где про это прочитать можно?
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Leshi, Вы писали:
L>Мне тут понадобилось переписать заново одну старую програмулину (написанную на С++). И я занялся изучением новомодных тенденций. Хотелось идти в ногу со временем и использовать что-то современное (ладно, кандидатами были C# и Java). Но беда заключается в том, что в старом коде используется множественное наследование почти везде. В двух словах, там есть несколько базовых функционалов (десятка три), реализованных своими классами. А рабочие классы используют то, что им надо (обычно от 5 до 15 родителей) и переопределяют некоторые операции. Так вот возник вопрос, как же без множественного наследования люди обходятся? Поделитесь опытом
L>ЗЫ: Вопрос о выборе средства разработки уже не стоит, С++ однозначно.
См. Паттерны дядьки Гаммы. Фабрика, шаблонный метод, стратегия и т.д.
ИМХО множественное наследование — от лукавого, т.е. появляется сильное связывание да еще и неявное. Если ты еще не убился с отлаживанием — рекомендую от м.н. не отказываться, через короткое время сам все поймешь .
Здравствуйте, Joker6413, Вы писали:
J>См. Паттерны дядьки Гаммы. Фабрика, шаблонный метод, стратегия и т.д.
Смотрел Мне не подходит J>ИМХО множественное наследование — от лукавого, т.е. появляется сильное связывание да еще и неявное.
И что? J>Если ты еще не убился с отлаживанием — рекомендую от м.н. не отказываться, через короткое время сам все поймешь .
Сколько же должно пройти времени? Я не первый день программирую на С++, почему-то желание отказаться от множественного наследования не возникало. Что я делаю не так?
VladD2 пишет:
> C>Тоже фигня — синтаксический сахар. > Ну, да. А for/while синтаксический сахар скрывающий ассемблерные команды.
Именно
> Синтаксический сахор облегчающий жизнь — это не фигня.
Все от его качества зависит.
> Что до DEFINITION, то по-моему — это неудачный варинт > traits/mix-in-ов. Самое простое и логичное что я видел — это когда > вводится специальный "тип класса" — trait. Его можно наследовать, но к > нему нельзя привести. Таким образом содержимое trait-ов просто > копируется в класс. Классы при этом могут иметь одиночное > наследование. Причем и trait. Таким образом trait-ы позволяют > подключать реализацию (как просто методов, так и интерфейсов).
Скорее помогли бы конструкции типа
class A implements I1, I2, I3
{
[delegate default I1] I1Impl impl1;
};
То есть делегировать непереопределенные методы из интерфейса I1 в
I1Impl. Реализуется такое до смешного просто, компилятору нужно
сгенерировать стабы методов такого вида:
Здравствуйте, VladD2, Вы писали:
VD>Ну, да. А for/while синтаксический сахар скрывающий ассемблерные команды.
Самое смешное что в шарпе for действительно синтаксический сахар, на уровне IL превращающийся в while. Далеко не все декомпиляторы умеют использовать for.
Здравствуйте, eao197, Вы писали:
E>А у Formatter-ов своих атрибутов не будет?
Что Вы имеете в виду под термином атрибут? Может быть переменные/поля/члены?
E>Как же Formatter будет про своего writter-а знать?
Formatter formatter = new Formatter(writer) — объект "писатель" отдается объекту "форматировщик" в его конструкторе, он его запоминает и затем пользуется им.
E>И имеют ли право потомки Formatter-а изменять writter-а во время работы?
Посредством объекта "писатель" осуществляется запись writer.Write(byte[] buffer, int offset, int size), при этом позиция записи сдвигается на +size, т. е. состояние писателя изменяется.
E>Или иерархию Formatter-ов вообще делать не нужно?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>А межмодульное наследование классов, вообще-то, не сильно-то поощряется ибо противоречит КОП.
VD>Бред. Это может проиворечить только кривым реализациям. Как, по-твоему, создавать разные библиотечные классы если раследоваться от классов в других модулях нельзя, а библиотека по опредлению другой модуль.
Основной принцип КОП (так как я его понимаю) гласит: модуль должен экспортировать только abstract class/interface/definition..., а также экспортировать фабрику по производству объектов реализующих указанные интерфейсы. Но сами по себе конкретные классы этих объектов-реализаторов модуль экспортировать не должен. Объясняется это тем, что модуль должен оставлять за собой право на изменение реализации в последующих версиях этого же самого модуля которые не приведут к тому чтобы пользователи этого модуля должны были бы перекомпилироваться при смене версии модуля (тоже самое должно быть справедливо при замене этого модуля на аналогичный модуль от другого производителя). КОП в том и состоит, что мы в любой момент можем из работающей системы изъять старый модуль и заменить его новым модулем (быть может от другого производителя) на лету без перезапуска системы и тем более без перекомпиляции (ибо у нас может просто не быть исходников).
P. S.
В оригинальных оберонах, т.е. откуда КОП пошло, JIT компиляции не было — вот поэтому и был наложен запрет на межмодульное наследование... При наличии JIT компиляции этот запрет, возможно, снимается...
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, eao197, Вы писали:
E>>А у Formatter-ов своих атрибутов не будет?
СГ>Что Вы имеете в виду под термином атрибут? Может быть переменные/поля/члены?
Имхо, понятия переменные (локальные, глобальные, автоматические, статические), поля (битовые?) и члены (методы-члены, атрибуты-члены) -- это все сильно перегруженные понятия. Поэтому раньше было принято использовать понятия -- метод (функция член) и атрибут (поле, член класса).
E>>Как же Formatter будет про своего writter-а знать?
СГ>Formatter formatter = new Formatter(writer) — объект "писатель" отдается объекту "форматировщик" в его конструкторе, он его запоминает и затем пользуется им.
Это я и так понимаю, запоминается writter куда? В атрибут. И, вероятно, не public-атрибут.
E>>И имеют ли право потомки Formatter-а изменять writter-а во время работы?
СГ>Посредством объекта "писатель" осуществляется запись writer.Write(byte[] buffer, int offset, int size), при этом позиция записи сдвигается на +size, т. е. состояние писателя изменяется.
Сергей, вы не понимаете суть вопроса. Пусть сначала Formatter был связан с writter-ом, который связан с файлом. Затем какому-то потомку захотелось перевязать этот же Formatter на writter, который связан с pipe. Можно ли такое допускать?
E>>Или иерархию Formatter-ов вообще делать не нужно?
СГ>Это по желанию, но скорее всего нет.
А почему нет? Пусть у меня есть Formatter, который строит XML и передает его в writter. Затем я делаю потомка для этого Formatter, который перед построением XML переводит все строки в UTF-8. Разве это запрещено? И нужно ли моему Utf8XmlFormatter-у знать, где XmlFormatter хранит ссылку на writter?
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Кодт, Вы писали:
К>У меня складывается впечатление, что есть какой-то глубокий изъян в методологии изучения и практики программирования. В основном он присущ изучению структурно-ориентированных языков. Вот что это за изьян: К>Мышление об объектах как о россыпи деталей (члены структуры, узлы графа, отдельные указатели и т.д.). К>Отсюда — написание функций, работающих со списком через указатель на головной узел; динамические массивы на уровне языка, управление которыми (перевыделение памяти, например) доступно кому попало; вот ещё добавляется боязнь скрытого состояния базовых объектов.
Самый простой объект — это действительно структура (члены структуры, узлы графа, отдельные указатели и т.д.).
Самая простая динамическая структура связанных объектов — это список.
Самый простой способ объединения объектов в один блок — массив на уровне языка программирования.
Самый простой взгляд на взаимодейсвие между объектами — это их композиция, а уж никак не "наследование скрытого состояния".
Так что "глубокий изъян" это, видимо, стремление к максимальной простоте.
Здравствуйте, eao197, Вы писали:
E>Это я и так понимаю, запоминается writter куда? В атрибут. И, вероятно, не public-атрибут.
Естественно. Но тут нет никакого наследования от какого-либо самостоятельного класса объектов. Здесь речь идет о композиции объектов.
E>Сергей, вы не понимаете суть вопроса. Пусть сначала Formatter был связан с writter-ом, который связан с файлом. Затем какому-то потомку захотелось перевязать этот же Formatter на writter, который связан с pipe. Можно ли такое допускать? E>А почему нет? Пусть у меня есть Formatter, который строит XML и передает его в writter. Затем я делаю потомка для этого Formatter, который перед построением XML переводит все строки в UTF-8. Разве это запрещено? И нужно ли моему Utf8XmlFormatter-у знать, где XmlFormatter хранит ссылку на writter?
Нет никаких потомков! Класс Formatter не является потомком от класа Writer. Это разные классы.
Самостоятельному объекту formatter ничего не известно о том куда самостоятельный объект writer осуществляет вывод.
Carrier, Reader, Writer, Scanner, Formatter, Client — это композиция из 6 разных объектов (классы которых не связаны друг с другом никаким отношением наследования). Стрелочки на рисунке обозначают поток информации от/в носител(я) Carrier, в роли которого может выступать кто угодно (File, Stream, Socket, ...) из/в Client.
Этот паттерн проектирования называется Carrier-Rider-Mapper.
Reader и Writer — это Rider-ы
Scanner и Formatter — это Mapper-ы
Каждый Carrier реализует свои собственные Reader и Writer (нет никакого наследования от других самостоятельных классов объектов).
Каждый Client реализует нужные только ему Scanner и Formatter (нет никакого наследования от других самостоятельных классов объектов).
Количество реализаций равно N + M, где N — количество разных Carrier-ов, а M — количество разных Client-ов. Если не использовать этот паттерн, а заставлять каждого клиента уметь работать непосредственно с каждым карриером, то количество реализаций взаимодействия из суммы N + M превратится в произведение N * M, что неэкономно.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Самый простой объект — это действительно структура (члены структуры, узлы графа, отдельные указатели и т.д.).
Самый простой объект — целостный, в котором не выделена внутренняя структура.
СГ>Самая простая динамическая структура связанных объектов — это список. СГ>Самый простой способ объединения объектов в один блок — массив на уровне языка программирования.
Разница между блоком и динамической структурой неясна. С моей т.з. самым простым методом объединения является неупорядоченная коллекция. Либо упорядоченная. Без завязки на то, как она будет храниться: массивом, списком, деревом...
СГ>Самый простой взгляд на взаимодейсвие между объектами — это их композиция, а уж никак не "наследование скрытого состояния".
Это, пожалуй, верно. Но, добавлю, что композиция объектов порождает третий объект, поведение которого требует доопределения. Композиция проста, но требует уточнения.
СГ>Так что "глубокий изъян" это, видимо, стремление к максимальной простоте.
Простота сама по себе является достоинством только, если с ней удобно работать. Для построения любого алгоритма достаточно двух конструкций: простого следования и условного перехода. Проще некуда. Нафиг-нафиг такую простоту!
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, eao197, Вы писали:
E>>Это я и так понимаю, запоминается writter куда? В атрибут. И, вероятно, не public-атрибут.
СГ>Естественно. Но тут нет никакого наследования от какого-либо самостоятельного класса объектов. Здесь речь идет о композиции объектов.
А я и не говорил про наследование в этом случае. Перечитай еще раз внимательно мои слова.
E>>Сергей, вы не понимаете суть вопроса. Пусть сначала Formatter был связан с writter-ом, который связан с файлом. Затем какому-то потомку захотелось перевязать этот же Formatter на writter, который связан с pipe. Можно ли такое допускать? E>>А почему нет? Пусть у меня есть Formatter, который строит XML и передает его в writter. Затем я делаю потомка для этого Formatter, который перед построением XML переводит все строки в UTF-8. Разве это запрещено? И нужно ли моему Utf8XmlFormatter-у знать, где XmlFormatter хранит ссылку на writter?
СГ>Нет никаких потомков! Класс Formatter не является потомком от класа Writer. Это разные классы.
Где я говорил о том, что Formatter является потомком Writter?
Я спросил про две вещи:
1. Можно ли делать свою иерархию классов для Formatter?
2. Если можно, то имеет ли право производный Formatter сменить ссылку на writter, которая была сохранена в базовом классе Formatter?
СГ>Самостоятельному объекту formatter ничего не известно о том куда самостоятельный объект writer осуществляет вывод. СГ>
СГ>Carrier, Reader, Writer, Scanner, Formatter, Client — это композиция из 6 разных объектов (классы которых не связаны друг с другом никаким отношением наследования). Стрелочки на рисунке обозначают поток информации от/в носител(я) Carrier, в роли которого может выступать кто угодно (File, Stream, Socket, ...) из/в Client.
СГ>Этот паттерн проектирования называется Carrier-Rider-Mapper. СГ>Reader и Writer — это Rider-ы СГ>Scanner и Formatter — это Mapper-ы
Мне кажется, что когда разговор уходит с простых вещей в область паттернов, то здравый смысл уходит куда-то далеко-далеко.
СГ>Каждый Carrier реализует свои собственные Reader и Writer (нет никакого наследования от других самостоятельных классов объектов).
Весело. Если в Unix-е чтение из файла, pipe и сокета ничем не отличается друг от друга, то зачем мне делать 3 разных Carrier (FileCarrier, PipeCarrier, SockerCarrier), а для них еще и 6 Reader/Writter (FileReader, FileWritter, PipeReader, PipeWritter, SocketReader, SocketWritter)?
Имхо, в этом случае ООП и не пахнет. А если и пахнет, то чем-то прогнившим.
СГ>Каждый Client реализует нужные только ему Scanner и Formatter (нет никакого наследования от других самостоятельных классов объектов).
Т.е. если клиенту MailAgent нужно читать из сокета SMTP трафик, то он должен создать свои Scanner и Formatter. И если я хочу создать свой SMSForwarder, который использует SMTP транспорт, то я так же должен создать собственные Scanner и Formatter? Даже не смотря на то, что их функциональность будет практически такой же как и для MailAgent?
СГ>Количество реализаций равно N + M, где N — количество разных Carrier-ов, а M — количество разных Client-ов. Если не использовать этот паттерн, а заставлять каждого клиента уметь работать непосредственно с каждым карриером, то количество реализаций взаимодействия из суммы N + M превратится в произведение N * M, что неэкономно.
Имхо, как раз то, что ты предлагаешь и приведет к N*M.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, tarkil, Вы писали:
T>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>Самый простой объект — это действительно структура (члены структуры, узлы графа, отдельные указатели и т.д.).
T>Самый простой объект — целостный, в котором не выделена внутренняя структура.
Разумеется. Если переменные этой записи не экспортируются, то такой объект снаружи выглядит как раз как объект с не выделеной внутренней структурой. Вот так:
DEFINITION Module1
TYPE
Object = RECORD END;
END Module1.
Что находится внутри записи известно только самому модулю, для всех остальных тип Module1.Object — это вещь в себе.
СГ>>Самая простая динамическая структура связанных объектов — это список. СГ>>Самый простой способ объединения объектов в один блок — массив на уровне языка программирования.
T>Разница между блоком и динамической структурой неясна.
Динамическая структура динамически изменяется. Блок — фиксирован, его можно целиком создать и целиком о нем потом забыть.
СГ>>Самый простой взгляд на взаимодейсвие между объектами — это их композиция, а уж никак не "наследование скрытого состояния".
T>Это, пожалуй, верно. Но, добавлю, что композиция объектов порождает третий объект, поведение которого требует доопределения. Композиция проста, но требует уточнения.
Нет не порождает. Третий объект нужен в языках не имеющих сборки мусора только для того чтобы ввести между объектами отношение хозяин/раб и создавать/уничтожать первые два объекта синхронно с третьим — так проще за памятью следить.
СГ>>Так что "глубокий изъян" это, видимо, стремление к максимальной простоте.
T>Простота сама по себе является достоинством только, если с ней удобно работать. Для построения любого алгоритма достаточно двух конструкций: простого следования и условного перехода. Проще некуда. Нафиг-нафиг такую простоту!
В таком случа добавляют "...но не проще." Целиком: "Сделай так просто на сколько это возможно, но не проще".
Здравствуйте, eao197, Вы писали:
E>1. Можно ли делать свою иерархию классов для Formatter? E>2. Если можно, то имеет ли право производный Formatter сменить ссылку на writter, которая была сохранена в базовом классе Formatter?
Делайте на здоровье и то и другое.
E>...зачем мне делать 3 разных Carrier... E>...я так же должен создать собственные Scanner и Formatter?...
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, eao197, Вы писали:
E>>1. Можно ли делать свою иерархию классов для Formatter? E>>2. Если можно, то имеет ли право производный Formatter сменить ссылку на writter, которая была сохранена в базовом классе Formatter?
СГ>Делайте на здоровье и то и другое.
Тогда следующий вопрос: если базовый тип какого-то Formatter-а не допускает простой смены writter-а в процессе работы, то как он может запретить делать это производному классу? Например, Formatter шифрует сообщение каким-либо блочным шифром. Для этого сообщение разбивается на блоки кратные, скажем, 8 байтам. Но вот в очередном сообщении оказался хвостик из 5 байт. Если поступит следующее сообщение, то Formatter просто объеденит эти 5 байт с 3-мя первыми байтами очередного сообщения и продолжит свою работу. Если Formatter выполнит операцию flush, то он добавить к 5-ти оставшимся байтам 3 нулевых байта и зашифрует их.
Но в этом случае Formatter должен защищать свою ссылку на writter-а, чтобы какой-то из нерадивых потомков не сменил writter-а пока есть оставшиеся от предыдущего сообщения байты. Имхо, логично здесь хранить ссылку на writter-а в виде private атрибута. А доступ к нему предоставлять производным классам через protected методы.
E>>...зачем мне делать 3 разных Carrier... E>>...я так же должен создать собственные Scanner и Formatter?...
СГ>Не делайте на здоровье ни того и ни другого.
Что значит не делать? Как же тогда паттерн Carrier-Rider-Mapper? Или это Zonnon-specific штука?
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Сергей Губанов, Вы писали:
К>>У меня складывается впечатление, что есть какой-то глубокий изъян в методологии изучения и практики программирования. В основном он присущ изучению структурно-ориентированных языков. Вот что это за изьян: К>>Мышление об объектах как о россыпи деталей (члены структуры, узлы графа, отдельные указатели и т.д.). К>>Отсюда — написание функций, работающих со списком через указатель на головной узел; динамические массивы на уровне языка, управление которыми (перевыделение памяти, например) доступно кому попало; вот ещё добавляется боязнь скрытого состояния базовых объектов.
СГ>Самый простой объект — это действительно структура (члены структуры, узлы графа, отдельные указатели и т.д.). СГ>Самая простая динамическая структура связанных объектов — это список. СГ>Самый простой способ объединения объектов в один блок — массив на уровне языка программирования. СГ>Самый простой взгляд на взаимодейсвие между объектами — это их композиция, а уж никак не "наследование скрытого состояния".
СГ>Так что "глубокий изъян" это, видимо, стремление к максимальной простоте.
Ты сам сказал "... но не проще".
Если я делаю декомпозицию задачи "мне нужен контейнер с последовательным двусторонним доступом, бла-бла-бла"
до "вот тебе объекты-узлы, собирай из них орграф-список, следи за целостностью и т.д."
то заказчик не порадуется. И меня не порадует.
В учебных целях (для понимания алгортимов реализации всей этой механики) — ради бога. Но в прикладных — первое, что нужно будет сделать — это найти наиболее абстрактный (в смысле — не привязанный к нюансам реализации) интерфейс.
Здравствуйте, eao197, Вы писали:
E> А доступ к нему предоставлять производным классам через protected методы.
Я вот что хочу сказать. Вы конечно можете наследоваться от классов как хотите, но я "проповедую" такой способ: Если уж наследоваться, то всегда это делать только от абстрактных классов. А от полноценных самостоятельных самодостаточных классов не наследоваться — вместо этого использовать композицию с уже готовыми объектами таких классов. Я считаю что так более правильно. У меня все.
E> Как же тогда паттерн Carrier-Rider-Mapper? Или это Zonnon-specific штука?
Zonnon тут не причем. Паттерн Carrier-Rider-Mapper был придуман Клеменсом Шиперски
Из документации к BlackBox:
The Carrier-Rider-Mapper separation goes back to a research project ["Insight ETHOS: On Object-Orientation in Operating Systems"; Clemens Szyperski; vdf, Zürich, 1992, ISBN 3 7281 1948 2] predating BlackBox. This project used several design patterns and design rules (e.g., avoidance of implementation inheritance) that are also described in Design Patterns. In the Design Patterns terminology, a Rider-Mapper combination (or Carrier-Mapper combination if there is no rider) forms a bridge pattern.
Здравствуйте, Кодт, Вы писали:
К>...первое, что нужно будет сделать — это найти наиболее абстрактный (в смысле — не привязанный к нюансам реализации) интерфейс.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, eao197, Вы писали:
E>> А доступ к нему предоставлять производным классам через protected методы.
СГ>Я вот что хочу сказать. Вы конечно можете наследоваться от классов как хотите, но я "проповедую" такой способ: Если уж наследоваться, то всегда это делать только от абстрактных классов. А от полноценных самостоятельных самодостаточных классов не наследоваться — вместо этого использовать композицию с уже готовыми объектами таких классов. Я считаю что так более правильно. У меня все.
Да вы, батенька, экстремист!
Похоже, что больше я вряд ли смогу чего добавить.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
C>То есть делегировать непереопределенные методы из интерфейса I1 в C>I1Impl. Реализуется такое до смешного просто, компилятору нужно C>сгенерировать стабы методов такого вида: C>
Здравствуйте, AndrewVK, Вы писали:
AVK>Самое смешное что в шарпе for действительно синтаксический сахар, на уровне IL превращающийся в while. Далеко не все декомпиляторы умеют использовать for.
while тоже нет. Есть конструкция проверки значения и конструкция перехода.
... << RSDN@Home 1.1.4 beta 4 rev. 359>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
VD>>Private-наследование уже выброшено. И, кстати, подилом. Дурь это.
E>Из C++ выброшено? E>А где про это прочитать можно?
На С++ свет клином не сошелся. Хотя согласен, говорить "выброшено" не корректно. Проще сказать, что кроме С++ его нигде толком то и нет.
... << RSDN@Home 1.1.4 beta 4 rev. 359>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 пишет:
> C>Получится примерно то же самое, что и трейты, но для этого не нужно > C>вводить никаких особых изменений в язык. > Зачем компилятору что-то делегировать, когда он может просто > скопировать код методов?
Копирование — это плохо. Вдобавок, мое решение более гибкое — я могу
менять реализацию делегата в run-time. Да и вообще, по-моему, гораздо
более простое решение.
Здравствуйте, Cyberax, Вы писали:
C>Копирование — это плохо. Вдобавок, мое решение более гибкое — я могу C>менять реализацию делегата в run-time. Да и вообще, по-моему, гораздо C>более простое решение.
C>То есть делегировать непереопределенные методы из интерфейса I1 в C>I1Impl. Реализуется такое до смешного просто, компилятору нужно C>сгенерировать стабы методов такого вида:
Смешно перестает быть тогда, когда происходит обратное приведение. Что вернет выражение (A)(I2)(new A())?
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Смешно перестает быть тогда, когда происходит обратное приведение. Что вернет выражение (A)(I2)(new A())?
Вот поэтому в COM агрегация устроена с прибамбасами. Чтобы семейство агрегатов и главного объекта выдавало наружу интерфейсы, QueryInterface'абельные друг к другу. Для этого каждый агрегат знает Controlling IUnknown главного объекта и все запросы по AddRef, Release, QueryInterface перенаправляет к нему.
Здравствуйте, Кодт, Вы писали: К>Вот поэтому в COM агрегация устроена с прибамбасами. Чтобы семейство агрегатов и главного объекта выдавало наружу интерфейсы, QueryInterface'абельные друг к другу. Для этого каждый агрегат знает Controlling IUnknown главного объекта и все запросы по AddRef, Release, QueryInterface перенаправляет к нему.
Я в курсе. COM как раз явственно демонстрирует тот факт, что для корректного решения проблемы каждый класс, который может стать жертвой агрегации (класс-примесь) обязан реализовывать специальные интерфейсы. В принципе, их реализация ничего сверхъестественного не представляет и даже может быть сгенерирована компилятором. Однако, если мы говорим уже о .Net, то возникают некоторые занятные особенности. В частности, вместо явного вызова QueryInterface, который может быть делегирован аггрегирующему объекту путем подмены реализации, в коде будет использован специальный опкод каста. Т.е. для корректного примешивания нужно просматривать весь код примеси в поисках специфических операций, и корректно заменять его на что-то.
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, VladD2, Вы писали:
СГ>Основной принцип КОП (так как я его понимаю) гласит: модуль должен экспортировать только abstract class/interface/definition..., а также экспортировать фабрику по производству объектов реализующих указанные интерфейсы.
Ссылку, плиз, на описание основных концепций.
Ты взвдашь догмы своих любимых технологий (которые сильно недоразвиты) за концептуальные пробемы. В нормально спроектированных компонетных средах (коими являются дотнет и Ява) таких ограничений нет. Можно экспортировать классы и создавать наследников в других модулях. Абстрактные классы, к слову, тоже могут иметь методы содержащие реализацию.
СГ> Но сами по себе конкретные классы этих объектов-реализаторов модуль экспортировать не должен. Объясняется это тем, что модуль должен оставлять за собой право на изменение реализации в последующих версиях этого же самого модуля которые не приведут к тому чтобы пользователи этого модуля должны были бы перекомпилироваться при смене версии модуля (тоже самое должно быть справедливо при замене этого модуля на аналогичный модуль от другого производителя).
Чущь. Чтобы интерфейс не изменялся достаточно его не изменять. Если он изменился и наследники использовали исходное описание, то соврешенно нормально, что их прийдется поправить и пересобрать. Компонетность от этого не убавляется. Изменение же внутренней реализации к проблемам приводить не обязано.
СГ> КОП в том и состоит, что мы в любой момент можем из работающей системы изъять старый модуль и заменить его новым модулем (быть может от другого производителя) на лету без перезапуска системы и тем более без перекомпиляции (ибо у нас может просто не быть исходников).
Ну, про заменую на лету — это ты придумывашь. Если модуль используюется, то любая полноценная ОС не даст его удалить. Можно конечно грузить две версии параллельно, но это уже другое решение. Без перекомпиляции? Тут проблем нет.
СГ>P. S. СГ>В оригинальных оберонах, т.е. откуда КОП пошло,
Акстись. Компонетный подход никакого отношения к Оберонам не имеет. Этой концепции сто лет.
СГ> JIT компиляции не было — вот поэтому и был наложен запрет на межмодульное наследование... При наличии JIT компиляции этот запрет, возможно, снимается...
В КОМ тоже джит компиляции небыло. Но подобных ограничений тоже небыло. Некоторые языки исползующие КОМ позволяли наследоваться от КОМ-классов.
В общем, прекрати ставить знак равенства между Обероном и КОП. Это уже не смешно.
... << RSDN@Home 1.1.4 beta 4 rev. 359>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Leshi, Вы писали:
J>>Если ты еще не убился с отлаживанием — рекомендую от м.н. не отказываться, через короткое время сам все поймешь . L>Сколько же должно пройти времени? Я не первый день программирую на С++,
Уверенность приходит с опытом. Читай внимательней:
Если ты еще не убился с отлаживанием
L>почему-то желание отказаться от множественного наследования не возникало. Что я делаю не так?
Потратишь побольше времени — желание возникнет... , и станет навязчивой идеей .
Здравствуйте, Cyberax, Вы писали:
C>Копирование — это плохо.
Чем.
C> Вдобавок, мое решение более гибкое — я могу C>менять реализацию делегата в run-time. Да и вообще, по-моему, гораздо C>более простое решение.
Я тоеж. Обертки еще никто не запрещал. Вот только если они ставятся в пику типизированному подходу, то — это очень плохо.
Делегирование — это не всегда приемлемое решение. Так оно приводит ктому, что я не смогу требовать от класса некоего контракта, а буду надяеяться на то, что мне подсунут приемлемую реализацию. Ну, и это банально медленеее. Обертка требует перезакгузки рекистров, а копирование происходит во время коппиляции.
В общем, приемущество именно то что trait-ы работают во врмея компиляции исключая накладные расходы и ошибки времени выполнения.
Они не являются заменой делегированию. Но и делегирование не является заменой trait.
trait — это безопасный вариант множественного наследования. По сути идея trait-а заключается в том, что trait-ы не могут иметь не абстрактных переменных и следовательно конструкторов. Это позволят им подмешивать чистую реализацию и избавляет от таких проблем МН как брилиантовое наследование и неоднозначности. К тому же trait проще для понимания.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
VD>>while тоже нет. Есть конструкция проверки значения и конструкция перехода.
AVK>Которые от while отличаются исключительно внешним видом
Ну, да. Буквы в авфовите тоже отличаются исключительно внешим видом. Хотя странно слышать, что две конструкции могут вообе быт похожи на одну.
while — это паттерн структурной конструкции. Его реализация — это две не структурных команды сравнения и перехода. Пожожего тут ничего нет. Напомню, что переход ожет быть потнециально и за пределы блоков (да их по просту нет в низкоуровневых языках вроде мсил-а или ассемблера).
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
А в ФЯ тебе копирование не нравится. Непоследовательно, однако А
копирование плохо тем, что просто происходит ненужное дублирование кода.
> Делегирование — это не всегда приемлемое решение. Так оно приводит > ктому, что я не смогу требовать от класса некоего контракта, а буду > надяеяться на то, что мне подсунут приемлемую реализацию.
А вот тут приходит на помощь слово final/sealed.
> Ну, и это банально медленеее. Обертка требует перезакгузки рекистров, > а копирование происходит во время коппиляции.
Как раз медленнее оно не будет — нормальный JIT способен будет
распознать код делегирующих методов и заоптимизировать их.
> trait — это безопасный вариант множественного наследования. По сути > идея trait-а заключается в том, что trait-ы не могут иметь не > абстрактных переменных и следовательно конструкторов. Это позволят им > подмешивать чистую реализацию и избавляет от таких проблем МН как > брилиантовое наследование и неоднозначности. К тому же trait проще для > понимания.
Так я и предлагаю, по сути, одну из реализаций автоматического
подмешивания реализации.
Cyberax пишет: > Так я и предлагаю, по сути, одну из реализаций автоматического > подмешивания реализации.
Кстати, я думаю никого не удивит, если я скажу что в VW ST именно такая
фишка и реализована.
При помощи аннотаций задаётся список селекторов метода которые будут
делегироватся и атрибут которому будут делегироваться вызовы. Точнее не
атрибут, а селектор метода результату которого будут делегироваться
вызовы. Всё происходит через #doesNotUnderstand: но ничего не мешает
нагенерить соответсвующих методов. Такая схема позволяет делегировать
разные сообщения различным получателям.
--
Andrei N.Sobchuck
JabberID: andreis@jabber.ru. ICQ UIN: 46466235.
А я и не говорил, что этого делать вот прямо совсем уж нельзя. Если отдавать себе отчет к чему это приводит, то это делать можно. Как известно, в Component Pascal можно экспортировать классы и создавать наследников в других модулях. Абстрактные классы, естественно, тоже могут иметь методы содержащие реализацию, более того — даже финальную реализацию, сверх более того (в отличие от Java и .NET) в Component Pascal абстрактные классы могут быть даже value-type (что в совокупности с value-type массивами позволяет писать программы вовсе никогда не использующие инструкции new — динамического распределения памяти)!!!!!!
СГ>> Но сами по себе конкретные классы этих объектов-реализаторов модуль экспортировать не должен. Объясняется это тем, что модуль должен оставлять за собой право на изменение реализации в последующих версиях этого же самого модуля которые не приведут к тому чтобы пользователи этого модуля должны были бы перекомпилироваться при смене версии модуля (тоже самое должно быть справедливо при замене этого модуля на аналогичный модуль от другого производителя).
VD>Чущь. Чтобы интерфейс не изменялся достаточно его не изменять. Если он изменился и наследники использовали исходное описание, то соврешенно нормально, что их прийдется поправить и пересобрать. Компонетность от этого не убавляется. Изменение же внутренней реализации к проблемам приводить не обязано.
А если модуль экспортирует только абстрактные классы/интерфейсы и фабрику по производству объектов реализующих эти интерфейсы, но ни за что на свете никогда не экспортирует реальные расширяемые классы, тогда никто не имеет возможности от них отнаследоваться, а значит абсолютно все лишены счастья когда либо в будущем перекомпилироваться при замене данного модуля другим содержащим немного другие расширяемые классы. Дело в том, что абстрактные классы/интерфейсы являются элементом самой архитектуры программы и поэтому (практически) никогда не изменяются, а реальные расширяемые классы как имплементаторы абстрактных, могут изменяться от версии к версии, и от производителя. КОП предполагает изготовление модулей на продажу, естественно, что продавать можно только указанные мной модули ибо только такие модули в любой момент можно заменить на аналогичные без перекомпиляции всей зависящей от них части системы.
СГ>> КОП в том и состоит, что мы в любой момент можем из работающей системы изъять старый модуль и заменить его новым модулем (быть может от другого производителя) на лету без перезапуска системы и тем более без перекомпиляции (ибо у нас может просто не быть исходников).
VD>Ну, про заменую на лету — это ты придумывашь. Если модуль используюется, то любая полноценная ОС не даст его удалить. Можно конечно грузить две версии параллельно, но это уже другое решение. Без перекомпиляции? Тут проблем нет.
Естественно, что все модули-клиенты предварительно тоже надо выгрузить (разобрать пирамиду импорта модулей)
СГ>>P. S. СГ>>В оригинальных оберонах, т.е. откуда КОП пошло,
VD>Акстись. Компонетный подход никакого отношения к Оберонам не имеет.
Ага, конечно! Еще скажите, что Клеменс Шиперски не является сооснователем Oberon Microsytems.
Здравствуйте, Joker6413, Вы писали:
L>>почему-то желание отказаться от множественного наследования не возникало. Что я делаю не так?
J>Потратишь побольше времени — желание возникнет... , и станет навязчивой идеей .
Я девять лет программирую и отлаживаю на С++. И ничего...
Не, разумеется, можно нагородить всякую фигню, используя любой инструмент.
Но знаете, надевать пробку на вилку только потому, что ею можно уколоться
Поэтому отказываться от МН там, где оно удобнее любых других решений — это нафиг.
Здравствуйте, Cyberax, Вы писали:
C>А копирование плохо тем, что просто происходит ненужное дублирование кода.
Видмо ты не понял. Если такой код уже есть, то или выдается ошибка, или происходит затирание. Весь смысл в том чтобы избежать дублирования.
>> Делегирование — это не всегда приемлемое решение. Так оно приводит >> ктому, что я не смогу требовать от класса некоего контракта, а буду >> надяеяться на то, что мне подсунут приемлемую реализацию.
C>А вот тут приходит на помощь слово final/sealed.
Не-а. Синклер тут рядом привел хороший пример нарушения контракта.
C>Как раз медленнее оно не будет — нормальный JIT способен будет C>распознать код делегирующих методов и заоптимизировать их.
Подумай. У тебя есть некий адрес объекта. По некоторому смещению в этом объекте лежит адрес объекта которому делегируется вызов. Как джит что-то сможет сделать? Он обязан будет взять ячейку с адресом получателя, скопировать ее в регист и вызвать метод. Далее ему нужно будет востановить исходный адрес чтобы продолжить работу.
А статическое делегирование и есть замена кода метода.
C>Так я и предлагаю, по сути, одну из реализаций автоматического C>подмешивания реализации.
Ты предлагаешь делегирование. Просто с упрощением синтаксиса. Этот паттерн известен давно и у него есть свои плюсы. Но есть и минусы. В качестве добавления реализации лучше подошли бы trait-ы, по-моему.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Т.е. основных концепций КОП зарадились "on 30-Dec-2004"? Во оно как.
Хотя о чем я. Никакого описания концепций по этой ссылке нет. Там куча ссылк. Ты приведи мне ссылку именно на определение основных концепций КОП.
VD>> В нормально спроектированных компонетных средах (коими являются дотнет и Ява) таких ограничений нет.
СГ>А я и не говорил, что этого делать вот прямо совсем уж нельзя. Если отдавать себе отчет к чему это приводит, то это делать можно.
Так значит можно? Ну, тогда нет вопросов. А отчет себе отдавать нужно всегда.
СГ>А если модуль экспортирует только абстрактные классы/интерфейсы и фабрику по производству объектов реализующих эти интерфейсы, но ни за что на свете никогда не экспортирует реальные расширяемые классы, тогда никто не имеет возможности от них отнаследоваться, а значит абсолютно все лишены счастья когда либо в будущем перекомпилироваться при замене данного модуля другим содержащим немного другие расширяемые классы.
Да? Ну, измени интерфейс такого абстрактного класса и вместе посмемся над тем как ты обойдешся без перекомпиляции и т.п.
В общем, запомни как отчий наш. Нормальная компонентная среда должна обеспечивать возможность обходиться без перекомпиляции если не изменилась используемая часть публичного интерфейса компонента. Все! Все остальное частности и домыслы.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 пишет:
> C>А копирование плохо тем, что просто происходит ненужное дублирование > кода. > Видмо ты не понял. Если такой код уже есть, то или выдается ошибка, > или происходит затирание. Весь смысл в том чтобы избежать дублирования.
Я подмешиваю один трейт в два класса — у меня один и тот же код будет
продублирован два раза.
> C>Как раз медленнее оно не будет — нормальный JIT способен будет > C>распознать код делегирующих методов и заоптимизировать их. > Подумай. У тебя есть некий адрес объекта. По некоторому смещению в > этом объекте лежит адрес объекта которому делегируется вызов. Как джит > что-то сможет сделать? Он обязан будет взять ячейку с адресом > получателя, скопировать ее в регист и вызвать метод. Далее ему нужно > будет востановить исходный адрес чтобы продолжить работу.
_Нормальный_ JIT, то есть HotSpot строит ветки кода, в которых
происходит изменение поля с адресом делегата. На эти ветки ставится хук,
который вызывает изменение зашитого статического адреса перехода в
JIT-коде этих методов.
> C>Так я и предлагаю, по сути, одну из реализаций автоматического > C>подмешивания реализации. > Ты предлагаешь делегирование. Просто с упрощением синтаксиса. Этот > паттерн известен давно и у него есть свои плюсы. Но есть и минусы. В > качестве добавления реализации лучше подошли бы trait-ы, по-моему.
Само по себе _добавление_ не особо нужно, обычно нужно, чтобы
добавленный код реализовывал какой-нибудь интерфейс. Поэтому мой метод
вполне себе нормален.
Здравствуйте, VladD2, Вы писали:
VD>Т.е. основных концепций КОП зарадились "on 30-Dec-2004"? Во оно как.
Вообще-то, это "Last modified on 30-Dec-2004".
VD>Хотя о чем я. Никакого описания концепций по этой ссылке нет. Там куча ссылк. Ты приведи мне ссылку именно на определение основных концепций КОП.
Там есть ссылки на его книги. Надо их читать.
Впрочем, большая часть мудрости доступна непосредственно из хелпа к BlackBox.
Здравствуйте, VladD2, Вы писали:
VD>В общем, запомни как отчий наш. Нормальная компонентная среда должна обеспечивать возможность обходиться без перекомпиляции если не изменилась используемая часть публичного интерфейса компонента. Все! Все остальное частности и домыслы.
Это возможно только при отказе от натуральной компиляции модулей в нативный машинный код в пользу компиляции в некий промежуточный язык с последующей JIT компиляцией.
Сейчас специально проверил. В одном модуле определил класс объектов с приватной переменной типа 32-битового целого числа и методом печатающим это число в консоль. В другом модуле определил класс потомок от первого класса, создаю объект и вызываю у него метод печати. Изготовил еще один модуль аналогичный первому, но приватную переменную сделал 64-битной. Внешний интерфейс класса объектов, стало быть, не изменился.
Подменил первый модуль вторым: в .NET — работает, в BlackBox — не работает: "Link Call Failed object TestExt1.BaseType^ inconsistently imported from TestExt2". Разница между BlackBox и .NET в JIT компиляции в последней, в то время как BlackBox компилирует модули непосредственно в нативный машинный код.
Так что моя оговорка:
СГ>P. S. СГ>В оригинальных оберонах, т.е. откуда КОП пошло, JIT компиляции не было — вот поэтому и был наложен запрет на СГ>межмодульное наследование... При наличии JIT компиляции этот запрет, возможно, снимается...
Здравствуйте, Cyberax, Вы писали:
C>Я подмешиваю один трейт в два класса — у меня один и тот же код будет C>продублирован два раза.
Тебя не должно трогать где что делает компилятор. Возможно он и одним вариантом кода обойдется, а возможно сдублирует его если типы того требуют.
C>_Нормальный_ JIT, то есть HotSpot строит ветки кода, в которых C>происходит изменение поля с адресом делегата. На эти ветки ставится хук, C>который вызывает изменение зашитого статического адреса перехода в C>JIT-коде этих методов.
Агащазблин.
C>Само по себе _добавление_ не особо нужно, обычно нужно, чтобы C>добавленный код реализовывал какой-нибудь интерфейс. Поэтому мой метод C>вполне себе нормален.
Никуда не годен твой метод. Глюков бльше чем пользы. Да и при наличии trait-ов интерфейсы уже не так становятся актуальны. Их можно очно так же реализовывать.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Это возможно только при отказе от натуральной компиляции модулей в нативный машинный код в пользу компиляции в некий промежуточный язык с последующей JIT компиляцией.
Агащазблин. Дельфи и Васик так работали спокойно.
СГ> СГ>Сейчас специально проверил. В одном модуле определил класс объектов с приватной переменной типа 32-битового целого числа и методом печатающим это число в консоль. В другом модуле определил класс потомок от первого класса, создаю объект и вызываю у него метод печати. Изготовил еще один модуль аналогичный первому, но приватную переменную сделал 64-битной. Внешний интерфейс класса объектов, стало быть, не изменился.
СГ>Подменил первый модуль вторым: в .NET — работает, в BlackBox — не работает: "Link Call Failed object TestExt1.BaseType^ inconsistently imported from TestExt2". Разница между BlackBox и .NET в JIT компиляции в последней, в то время как BlackBox компилирует модули непосредственно в нативный машинный код.
СГ>Так что моя оговорка:
СГ>>P. S. СГ>>В оригинальных оберонах, т.е. откуда КОП пошло, JIT компиляции не было — вот поэтому и был наложен запрет на СГ>межмодульное наследование... При наличии JIT компиляции этот запрет, возможно, снимается...
СГ>оказалось не напрасной.
Дермом твой Блэкбокс является. Отсюда и проблемы. А все оговорки от незнания. Создай КОМ-объект на чем угодно и попробуй с ним. Пока публичный интерфейс будет низменен проблем не будет.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 пишет:
> C>_Нормальный_ JIT, то есть HotSpot строит ветки кода, в которых > C>происходит изменение поля с адресом делегата. На эти ветки ставится > хук, > C>который вызывает изменение зашитого статического адреса перехода в > C>JIT-коде этих методов. > Агащазблин.
Не "агащазблин", а RTFM. HotSpot именно так и работает, причем еще он
точно так же инлайнит виртуальные вызовы. Могу показать место в
исходниках JDK, где об этом говорится.
> C>Само по себе _добавление_ не особо нужно, обычно нужно, чтобы > C>добавленный код реализовывал какой-нибудь интерфейс. Поэтому мой метод > C>вполне себе нормален. > Никуда не годен твой метод. Глюков бльше чем пользы. Да и при наличии > trait-ов интерфейсы уже не так становятся актуальны. Их можно очно так > же реализовывать.
Стоп. Интерфейсы НИКУДА не денутся, так как это средство абстракции.
Трейты могут помочь только в их реализации.
Здравствуйте, VladD2, Вы писали:
VD>Дермом твой Блэкбокс является. Отсюда и проблемы. А все оговорки от незнания. Создай КОМ-объект на чем угодно и попробуй с ним. Пока публичный интерфейс будет низменен проблем не будет.
Приехали. А я ведь именно об этом и говорю, перечитайте:
СГ>....А если модуль экспортирует только абстрактные классы/интерфейсы и фабрику по производству объектов реализующих эти интерфейсы, но ни за что на свете никогда не экспортирует реальные расширяемые классы,..........
COM объект — это и есть объект-реализатор интерфейса. То есть модель компонентных объектов (COM) в точности следует всем директивам компонентного программирования (COP). Экспорту, в COM, как раз подлежат только интерфейсы и фабрики. В COM нельзя экспортировать (расширяемый) класс объектов, можно лишь их фабрику, т.е. не класс, а сами объекты.
Здравствуйте, VladD2, Вы писали:
VD>Дермом твой Блэкбокс является. Отсюда и проблемы.
Кстати, не гоже так отзываться о продукте первоначально разработанного как кросплатформенная среда под виндос-95 и Макинтош (и которому в прошлом году, кстати, исполнилось 10 лет), но тем не менее он по скорости работы обгоняет современный .NET в несколько раз! Уже позабыли?
В данном конкретном тесте, .NET-товский сборщик мусора работал в 163/50 = 3.26 раза медленнее чем BlackBox-совский сборщик мусора. Если вспомнить про задачку с N^2 ссылками между N объектами, то там тоже .NET-товский сборщик мусора работал более чем в 3 раза медленнее чем BlackBox-совский сборщик мусора.
N кол.связей один объект вся структура BlackBox .NET Отношение времен .NET/BlackBox
2000 4 млн 8 Kb 16 Mb 0.23 сек 0.83 сек 3.60 раз
3000 9 млн 12 Kb 36 Mb 0.55 сек 2.27 сек 4.13 раз
4000 16 млн 16 Kb 64 Mb 1.17 сек 3.99 сек 3.41 раз
5000 25 млн 20 Kb 100 Mb 1.70 сек 6.37 сек 3.75 раз
6000 36 млн 24 Kb 144 Mb 2.67 сек 10.03 сек 3.76 раз
7000 49 млн 28 Kb 196 Mb 4.17 сек 18.12 сек 4.35 раз
8000 64 млн 32 Kb 256 Mb 4.12 сек 22.22 сек 5.39 раз
И что же это такое получается? Вот уже на двух совершенно разных задачах .NET-товский сборщик мусора работает более чем в 3 раза медленнее чем BlackBox-совский сборщик мусора. Как это объяснить? Может быть в следующей версии .NET сборщик мусора станет более шустрым?
Здравствуйте, Сергей Губанов, Вы писали:
СГ>COM объект — это и есть объект-реализатор интерфейса. То есть модель компонентных объектов (COM) в точности следует всем директивам компонентного программирования (COP). Экспорту, в COM, как раз подлежат только интерфейсы и фабрики. В COM нельзя экспортировать (расширяемый) класс объектов, можно лишь их фабрику, т.е. не класс, а сами объекты.
Экспортируется публичный интерфейс. Точка! Его вид не имеет значения. Нет никаких проблем в наследовании или еще чем-то объектно-ориентированном.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Кстати, не гоже так отзываться о продукте первоначально разработанного как кросплатформенная среда под виндос-95 и Макинтош (и которому в прошлом году, кстати, исполнилось 10 лет), но тем не менее он по скорости работы обгоняет современный .NET в несколько раз! Уже позабыли?
Отзываюсь о вещах по их сути. Уж извини. Тебе уже не раз показывали, что стоит твой Блэкбокс в целом, и его ЖЦ в частности.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
E>>>А я вот не понимаю, что плохого в том, что базовый класс имеет private-атрибуты
СГ>>1) В случае множественного наследования возникает вопрос сколько копий private-членов будет если среди предков такой класс встречается больше одного раза.
E>Если говорить про C++ -- то столько, сколько раз базовый класс был невиртуальным базовым классом.
А если хотя бы раз был виртуальным, то плюс еще ровно один раз на все виртуальные вхождения.
Здравствуйте, moudrick, Вы писали:
E>>>>А я вот не понимаю, что плохого в том, что базовый класс имеет private-атрибуты
СГ>>>1) В случае множественного наследования возникает вопрос сколько копий private-членов будет если среди предков такой класс встречается больше одного раза.
E>>Если говорить про C++ -- то столько, сколько раз базовый класс был невиртуальным базовым классом.
M>А если хотя бы раз был виртуальным, то плюс еще ровно один раз на все виртуальные вхождения.
Во-первых, виртуальное вхождение всегда одно.
А во-вторых, я специально не упоминал случая, когда в одну иерархию класс входит и как виртуальный базовый и как невиртуальный базовый -- поскольку в этих случаях начинается редкосный геморрой.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Перекуём баги на фичи!
Даже думать не хочется. А так у меня получается, что я разбиваю на маленькие кусочки (даже там, где полсотни методов уже используется наследование). В результате классы имеют по три десятки методов (максимум), а последний имеет ну от силы полсотни (пока 14, но я еще не закончил).
, и станет навязчивой идеей 
