Здравствуйте, McSeem2, Вы писали:

P>>Опять неверно. Программа без классов и наследования плохо поддается статическому анализу.
MS>А программа с классами, но без наследования?

Это то же самое, как если бы классов не было вовсе.

Здравствуйте, Костя Ещенко, Вы писали:

КЕ>На мой взгляд наиболее расширяемым (и при этом недорогим) решением является введение в INode функции а-ля QueryInterface. Отсюда следует что все-же придется ручками перечислять интерфейсы в реализации QueryInterface. Кроме того каждому интерфейсу в рантайме должен соответствовать некий идентификатор. Короче очень похоже на запрос интерфейса в COM.
Я сейчас пишу под .NET со всеми вытекающими...

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Если вопрос не праздный,
Ну не то чтобюы совсем празный... в принципе я только подобную иерархию изобразил. Полет нормальный...
ПК>то полагаю, что тебе может показаться очень интересной книга: John Vlissides. Pattern Hatching: Design Patterns Applied (Джон Влиссидес. Применение шаблонов проектирования. Дополнительные штрихи) — заметную часть книги занимает анализ как раз аналогичного случая.
Нет у меня этой книги.
ПК>Краткий вывод такой: в данной ситуации оправдано использование "жирных" интерфейсов.
А можно чуть мение краткий? Ибо у меня есть сомнения в оправдоности жирных интерфейсов.

ЗЫ Я привел выдуманую иерархию. В моем случае элементы дерева очень сильно различаются. Общие у них только то что они являются элементами одного и тогоже дерева. И только некоторые из них могут иметь детей при том вполне определенных типов.
ЗЗЫ Отображения элементов не имеют между собой ни чего общего.
ЗЗЗЫ В моем случае интерфейс получится ооочень толстым. А самое главное я не вижу ни одного плюса.

Здравствуйте, McSeem2, Вы писали:

MS>Ты будешь мощно смеяться — не знаю как. И никто толком не знает.
Вот и я о томже...
MS>Рискну модифицировать и продолжить иерархию.
Вот не надо модифицировать иерархию. Я тоже не дурак и прекрасно знаю чем грозит такое "модифицирование" (тут болие уместно извращение) иерархии...
Я использую лишь наследование интерфейсов. (*) Наследование реализации в данной иерархии спользовано лишь для INode и INodeWithChildren
Общие вещи для остальных классов реализваны через агрегацию.(в С++ я бы использовал приватное наследование в прочем это детали)

MS>Отвечая на вопрос, скажу, что я бы предпочел схему "примерки" интерфейсов без какого-либо наследования.
Рассамтриваю динамический случай.
1)Можно случайно подцепить объект у которого просто подошол набор методов что ИМХО не есть гуд.
2)Можно случайно опечататся и потом долго искать а кокого не подцепляется нужный объект
3)Эффективно реализовать очень сложно.(если вобще возможно)
MS>У нас есть одна единственная сущность — нода.
У меня есть две сущьности "нода" и "нода с детьми" в принципе их можно объеденить но я счел что болие умесно будет их разделить для улучшение диагностики ошибок.(и как бесплатный бонус некоторое уменьшение издержек)
MS>Мы берем эту ноду и пытаемся "примерять" разные интерфейсы, существующие независимо от имплементации. Ну, примерно, как в Хероне.
Не уверен что это всегда оправдано.
MS>Вот еще-бы как-то это сделать совсем динамически...
Во во...

(*)Эта иерархия не 1 в 1 то что я сейчас делаю но некоторое представление о структуре дает.

Здравствуйте, WolfHound, Вы писали:

WH>ЗЫ Я привел выдуманую иерархию. В моем случае элементы дерева очень сильно различаются. Общие у них только то что они являются элементами одного и тогоже дерева. И только некоторые из них могут иметь детей при том вполне определенных типов.
Зачем ты вообще сделал их элементами дерева? IMHO, если "состоять в дереве" не является их прямой функцией, то дерево нужно сделать отдельно от этих типов. Хранить объект в Tag или чем там еще узла дерева и синхронизить структуру дерева с объектами когда надо. Дерево строишь билдером, синхронизируешь состояние листенерами. Грамотное и гибкое решение.

WH>ЗЗЫ Отображения элементов не имеют между собой ни чего общего.
Тем более.

WH>ЗЗЗЫ В моем случае интерфейс получится ооочень толстым. А самое главное я не вижу ни одного плюса.
Толще, чем у Control? Сомневаааюсь.

WolfHound пишет:

> Я использую лишь наследование интерфейсов. (*) Наследование реализации
> в данной иерархии спользовано лишь для INode и INodeWithChildren

Ну так и это нафиг убери. У тебя же интерфейсы, зачем делать
INodeWithChildren? Сделай интерфейс IChildrenContainer.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Poudy, Вы писали:

P>Зачем ты вообще сделал их элементами дерева?
За тем что логика модели такова что они являются элементами дерева.
P>IMHO, если "состоять в дереве" не является их прямой функцией,
Правда? А по моему очень даже является.(в данном случае дерево это не отображение, а структура данных)
P>то дерево нужно сделать отдельно от этих типов.
Зачем? Хотя то дерево которое используется в System.Windows.Forms.TreeView сделано действительно отдельно от модели (и для оптимизации в свойстве Tag хранится ссылка на объект модели) ибо как я уже говорил отображений несколько...
P>Хранить объект в Tag или чем там еще узла дерева и синхронизить структуру дерева с объектами когда надо. Дерево строишь билдером, синхронизируешь состояние листенерами. Грамотное и гибкое решение.
При отображении этого дела в TreeView я именно так и поступаю.
Но никак не могу понять как ты предлагаешь строить дерево по не организованным объектам?
Как ты предлагаешь гарантировать целостность модели? В смысле не дать нарушить инвариант модели какимнибудь левым действием отображения. У меня за целостностью следит сама модель. Как я уже говорил отображений несколько и следить за целостностью модели в каждом из них Причем большая часть контроля выполняется компилятором C# и рантаймом .НЕТ благодоря именно тонким интерфейсам(ну не сможешь ты заменить колеса у кошки... ну нет в ее интерфейса таких функций... и получить интерфейс машины у кошки тоже ни кто не даст).

WH>>ЗЗЗЫ В моем случае интерфейс получится ооочень толстым. А самое главное я не вижу ни одного плюса.
P>Толще, чем у Control? Сомневаааюсь.
Если ты про System.Windows.Forms.Control то он то тут причем?
А в моем случае в место нескольких тонких интерфейсов которые имеют между собой меньше общего чем машина, картошка и кошка... получится один толстый которые все это совмещает? Зачем?
Если с Control в принципе понятно чем руководствовались авторы создавая толстый интерфейс (хотя и тут есть с чем поспорить но это тема для отдельного флейма) то в моем случае нет вобще никаких предпосылок создовать толстый интерфейс

Здравствуйте, Cyberax, Вы писали:

>> Я использую лишь наследование интерфейсов. (*) Наследование реализации
>> в данной иерархии спользовано лишь для INode и INodeWithChildren
C>Ну так и это нафиг убери. У тебя же интерфейсы, зачем делать
C>INodeWithChildren? Сделай интерфейс IChildrenContainer.
Гм. Тоже вариант. Спасибо я подумаю.

Здравствуйте, Poudy, Вы писали:

P>Я не согласен с AndrewVK, что наследование классов (классов?) необходимо для полиморфизма. Для динамических языков без наследования вопрос полиморфизма вообще не стоит (как в JavaScript). Полиморфизма можно добиться одними интерфейсами. Возможно, он имел в виду другой полиморфизм — полиморфизм обобщенных алгоритмов, выражаемых в виде класса.

Надо понимать что все, что я писал, валидно в контексте статически типизированных языков. Для языков без статической типизации совсем другая песня. И опять же — мы все прекрасно знаем чем мы платим за дополнительную гибкость в динамических языках.

P>Как я это вижу, наследование классов можно считать чисто удобным механизмом повторного использования кода.

Не только. Наследование (в статически типизируемых языках) это как минимум две вещи — наследование интерфейса и наследование реализации. Главная хитрость — уметь применять оба аспекта таким образом, чтобы не возникало описанных нехороших эффектов.

Здравствуйте, McSeem2, Вы писали:

AVK>> 1) В моем примере преобразования от базового к производному не было

MS>Упрек безусловно справедливый, если придерживаться рамок C# или Java. Но наследование интерфейсов — все равно остается наследованием.

Да. Но когда мы говорим о наследовании исключительно интерфейсов, то единственный смысл в наследовании это наложить на реализацию наследника констрейнт обязательной реализации интерфейса предка. Если ориентироваться только на это, а не на классические упражнения с фруктами, деревьями и геометрическими фигурами, то все будет в порядке.
И в наследовании реализаций тоже ничего плохого нет, если не делать это наследование публичным.

MS>Отвечая на вопрос, скажу, что я бы предпочел схему "примерки" интерфейсов без какого-либо наследования. У нас есть одна единственная сущность — нода. Мы берем эту ноду и пытаемся "примерять" разные интерфейсы, существующие независимо от имплементации.

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

MS> Ну, примерно, как в Хероне.

А как в Хероне я так однозначно и не понял. Ты с ПК говорите что там чистая статика, а при попытке полиморфизма компилятор ругается, c-smile говорит о некоей прозрачной механике подстановки полиморфизма когда нужно, но как это работает так и не сказал (я услышал только про какие то таблицы, которые строит компилятор, но их потенциальный размер навевает сомнения).

Здравствуйте, Костя Ещенко, Вы писали:

КЕ>На мой взгляд наиболее расширяемым (и при этом недорогим) решением является введение в INode функции а-ля QueryInterface. Отсюда следует что все-же придется ручками перечислять интерфейсы в реализации QueryInterface. Кроме того каждому интерфейсу в рантайме должен соответствовать некий идентификатор. Короче очень похоже на запрос интерфейса в COM.

Одна из проблем COM — это то что от любого интерфейса нужно уметь шагнуть к любому другому интерфейсу, при этом объект остаётся как-бы "за кулисами" и к нему доступа нет. Отсюда известные грабли с наследованием реализаций.

Здравствуйте, Костя Ещенко, Вы писали:

КЕ>На мой взгляд наиболее расширяемым (и при этом недорогим) решением является введение в INode функции а-ля QueryInterface. Отсюда следует что все-же придется ручками перечислять интерфейсы в реализации QueryInterface. Кроме того каждому интерфейсу в рантайме должен соответствовать некий идентификатор.

Фактически полное дублирование рефлекшена. И что это даст?

Здравствуйте, Cyberax, Вы писали:

Здравствуйте, WolfHound, Вы писали:

P>>Зачем ты вообще сделал их элементами дерева?
WH>За тем что логика модели такова что они являются элементами дерева.
Хорошо.

P>>IMHO, если "состоять в дереве" не является их прямой функцией,
WH>Правда? А по моему очень даже является.(в данном случае дерево это не отображение, а структура данных)
Я не знаю твоей конткретной задачи. Насчет примера ты сам говорил, что он искусственный. Если по-твоему являются, пусть будет так.

P>>то дерево нужно сделать отдельно от этих типов.
WH>Зачем? Хотя то дерево которое используется в System.Windows.Forms.TreeView сделано действительно отдельно от модели (и для оптимизации в свойстве Tag хранится ссылка на объект модели) ибо как я уже говорил отображений несколько...
Ок ок.

P>>Хранить объект в Tag или чем там еще узла дерева и синхронизить структуру дерева с объектами когда надо. Дерево строишь билдером, синхронизируешь состояние листенерами. Грамотное и гибкое решение.
WH>При отображении этого дела в TreeView я именно так и поступаю.
WH>Но никак не могу понять как ты предлагаешь строить дерево по не организованным объектам?
Я имел в виду: зачем тебе одно общее явное дерево и объекты в виде его узлов.
А строить билдером. Так или иначе, они всё равно организованы. Билдер — просто вариант реализации, с теми же даункастами. Однако я уже вижу, что перед тобой стоит другая задача.

WH>Как ты предлагаешь гарантировать целостность модели? В смысле не дать нарушить инвариант модели какимнибудь левым действием отображения. У меня за целостностью следит сама модель. Как я уже говорил отображений несколько и следить за целостностью модели в каждом из них Причем большая часть контроля выполняется компилятором C# и рантаймом .НЕТ благодоря именно тонким интерфейсам(ну не сможешь ты заменить колеса у кошки... ну нет в ее интерфейса таких функций... и получить интерфейс машины у кошки тоже ни кто не даст).
Целостность модели, если она проверяется моделью, нарушить всё равно нельзя. Просто я не достаточно ясно выразился про дерево. Ты хочешь древовидную структуру. Я отметил, что совсем не обязательно давать для этого объектам общий интерфейс узла.

WH>>>ЗЗЗЫ В моем случае интерфейс получится ооочень толстым. А самое главное я не вижу ни одного плюса.
P>>Толще, чем у Control? Сомневаааюсь.
WH>Если ты про System.Windows.Forms.Control то он то тут причем?
WH>А в моем случае в место нескольких тонких интерфейсов которые имеют между собой меньше общего чем машина, картошка и кошка... получится один толстый которые все это совмещает? Зачем?
Я не знаю, сколько там общего у твоих объектов . Если всё так, то нет, не нужно писать большой интерфейс.

Давай я буду писать понятнее и точнее.
Попытаюсь пошагово проанализировать твою искуственную задачу с файлами, а заодно дам понять, что же я понимаю под проблемным доменом (областью).

Итак, у нас есть нефиксированное множество типов объектов файловой системы, которые необходимо представить в виде их естественной структуры — дерева. При этом одни объекты отличаются от других примерно как рыбы от пуговиц.

Существует 3 необходимых функциональности:
1. Построение дерева.
2. Просмотр.
3. Выполнение действий.

Я считаю, что декомпозицию в классы необходимо делать по функциональному принципу. Буквально: каждый отвечает за своё.

В данном случае у нас есть несколько таких функций или обязанностей, лежащих на каждом объекте.
1. Содержаться в контейнере.
2. Быть контейнером элементов или, точнее — обслуживать контейнер элементов. Управлять им.
3. Предоставлять расширенную информацию о себе в текстовом виде + картинки, иконки.
4. Выполнять общие функции, вроде DefaultAction.
5. Выполнять специфические функции.

Соответственно, в системе я бы завел минимум 5 классов:
1. Элемент контейнера — извещает контейнер о добавлении и удалении себя из него (friend || internal методы).
2. Контейнер — извещает элементы о добавлении и удалении их из себя (friend || internal методы), наследован от элемента.
3. Дескриптор, содержащий описание некоторого объекта.
4. Объект файловой системы, содержащий Name, Path и DefaultAction.
5. Конкретный файл.
(на самом деле, если дерево не предполагается заюзать повторно, классы 1 и 4 можно объединить в один)

Рассморим всё по порядку с чувством, с толком, с расстановкой

В C# нет множественного наследования и мы можем выбрать только один класс в качестве корня общей иерархии, поместив в него реализации наиболее общих и нужных методов. Я говорю не об интерфейсе рута, а именно о готовой реализации.
В данном случае можно выбрать (1), (4) или их join.

Элемент и контейнер
Как и описано выше, элемент и контейнер задают протокол работы друг с другом. Требование "в каждой папке могут находиться файлы только определенного типа" не нарушается, т.к. контейнер не обязан реализовывать само хранение элементов. Ему достаточно определить только интерфейс для перебора элементов. Для простоты обхода дерева, можно реализовать implicit IEnumerable прямо в классе Элемента.

А можно сделать, чтобы контейнер также и хранил элементы. Для этого в его интерфейсе должны присутствовать ICollection, IList, а также метод CanAdd(Accept)Item(Element). Т.е. контейнер позволяет потомкам производить валидацию данных.

Дескриптор
При фиксированном пользовательском интерфейсе вводить дескриптор нет смысла. Все его свойства и методы можно легко запихнуть в Элемент или Объект файловой системы. Но! Если у нас существует поддержка многих языков для подписей к файлам или возможность менять иконку для отображения, ну и так далее. То лучше воспользоваться Дескриптором.

На это есть как минимум 2 причины:
1. Описание требуется другим системам и таких систем может быть много. Т.е. потенциально требуется неизвестное количество типов описаний.
2. Вынесение дескриптора в отдельную функциональность и класс позволяет реализовать несколько гибких механизмов получения и настройки описания, чем простое element.DescriptionString.

Имея класс Дескриптора, мы можем создать класс Сервис Дескрипторов, конструирующий описания для переданных ему объектов. Сервис дескрипторов может делать следующие вещи:
1. Просто конструировать объект описания по значениям свойств объекта и атрибутов, прикрепленных е его типу.
2. Возвращать default описание или заполнять недостающие значения.
3. Хостить в себе chain of responsibility для конструирования или модификации описания.
4. Рассылать события об изменении описания для определенного типа объектов или конкретного объекта.

Объект файловой системы
Ну понятно: содержит общие свойства и методы. Но даже тут есть несколько тонкостей.

Во-первых: как я уже говорил, можно слить его с Элементом. Если не сливать, то появляется проблема отсутствия множественного наследования при необходимости быть ОбъектомФС и Папке (контейнеру) и Файлу(элементу). Проблема решается агрегированием. Так или иначе, обращение к элементам папки будет проходить не так: folder[6], а так: folder.Items[6].

Агрегированием сущностей и внутренним связыванием с ними решается много проблем, когда есть проблемы с множественным наследованием. Итак мы имеем в дереве одни только элементы, но некоторые из них содержат в себе контейнеры элементов. Для нетипизированного обхода дерева остается всё тот же implicit IEnumerable на всех элементах.

Во-вторых: DoDefaultAction желательно делегировать или хотя бы дать возможность для делегирования. Для выполнения DoDefaultAction желательно использовать медиатор. Этот медиатор будет либо передавать сразу управление ОбъектуФС, который его(медиатор) хостит. Либо вызывать сервис в определенном контексте, получая этот контекст либо из thread, либо обходя в его поиске Parent'ы, либо вызывая синглтон (который также может пройтись по Parent'ам для выяснения соответствия контексту).

Конкретный файл
Ну тут всё просто. То, что не вошло ни в одну систему, не пользуется напрямую GUI'ем и не присутствует в контекстных меню, ощутимо находится здесь в виде типизированных публичных методов и свойств и юзается при создании элементов, а также в редких случаях после downcast'а в кривых обработчиках.

Надеюсь, что написал подробно и понятно. Жду от тебя неленивого ответа .

Здравствуйте, AndrewVK, Вы писали:

AVK>Надо понимать что все, что я писал, валидно в контексте статически типизированных языков. Для языков без статической типизации совсем другая песня. И опять же — мы все прекрасно знаем чем мы платим за дополнительную гибкость в динамических языках.
Всё так

P>>Как я это вижу, наследование классов можно считать чисто удобным механизмом повторного использования кода.
AVK>Не только. Наследование (в статически типизируемых языках) это как минимум две вещи — наследование интерфейса и наследование реализации. Главная хитрость — уметь применять оба аспекта таким образом, чтобы не возникало описанных нехороших эффектов.
Я писал выше о наследовании интерфейса, и имел здесь в виду, что при условии наличия наследования интерфейса вроде как во всех приличных языках, в спорах можно рассматривать только эффект повторного использования кода.

LCR пишет:

> КЕ>На мой взгляд наиболее расширяемым (и при этом недорогим) решением
> является введение в INode функции а-ля QueryInterface. Отсюда следует
> что все-же придется ручками перечислять интерфейсы в реализации
> QueryInterface. Кроме того каждому интерфейсу в рантайме должен
> соответствовать некий идентификатор. Короче очень похоже на запрос
> интерфейса в COM.
> Одна из проблем COM — это то что от любого интерфейса нужно уметь
> шагнуть к любому другому интерфейсу, при этом объект остаётся как-бы
> "за кулисами" и к нему доступа нет. Отсюда известные грабли с
> наследованием реализаций.

Багов с наследованием реализации в COM нет. Так как наследования
реализации нет как класса.

COM — это просто стандарт на расположение методов в vtbl. Встроенными
средствами _С++_ нельзя приспособить наследование так, чтобы методы
располагались в vtbl в правильном порядке для COM. Но принципиальных
проблем с наследованием реализации в COM нет, есть даже и ее частичная
имплементация в виде аггрегирования.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Poudy, Вы писали:

P>Я писал выше о наследовании интерфейса,

Я, честно говоря, этого момента не уловил. Твой резюм:

Каждый проблемный домен должен содержать свой центральный класс, содержащий наиболее полную (а не наиболее непротиворечивую) для данного домена функциональность.

косвенно намекает именно на комбинированное наследование — интерфейса и реализации. Поскольку если мы говорим о наследовании интерфейса только то, как правило, никакого единого центрального интерфейса не существует и уж точно ни о какой содержащейся функциональности речи вобще идти не может.

Здравствуйте, AndrewVK, Вы писали:

AVK>Я, честно говоря, этого момента не уловил. Твой резюм:
AVK>

Каждый проблемный домен должен содержать свой центральный класс, содержащий наиболее полную (а не наиболее непротиворечивую) для данного домена функциональность.

AVK>косвенно намекает именно на комбинированное наследование — интерфейса и реализации. Поскольку если мы говорим о наследовании интерфейса только то, как правило, никакого единого центрального интерфейса не существует и уж точно ни о какой содержащейся функциональности речи вобще идти не может.
Да, всё так. Наследование реализации я и имел в виду.

Также я считаю, что перепрыгивание с дерева классов на дерево интерфейсов проблемы не решает. Дело ведь не в полиморфном коде, а в громоздкости иерархии и кастах, IMHO.

Здравствуйте, Poudy, Вы писали:

P>Да, всё так. Наследование реализации я и имел в виду.
Тьфу, коряво как-то выразился .

Имел в виду, что в

Каждый проблемный домен должен содержать свой центральный класс, содержащий наиболее полную (а не наиболее непротиворечивую) для данного домена функциональность.

речь идет о комбинированном наследовании. Таким образом я пытаюсь громоздкую интерфейсную иерархию свести к более простой и короткой, переложив больше обязанностей на реализацию рутового интерфейса в рутовом классе. При этом вопросы полиморфности хорошо решаются делегированием и в целов классов и интерфейсов получается меньше.

Здравствуйте, Poudy, Вы писали:

P>Также я считаю, что перепрыгивание с дерева классов на дерево интерфейсов проблемы не решает.

Ну если 1 в 1 копировать то не решает. Вот только из интерфейсов как правило полноценное дерево никто не делает. Как я уже писал — наследование в этом случае используется исключительно в качестве констрейнта.

P> Дело ведь не в полиморфном коде, а в громоздкости иерархии и кастах, IMHO.

Дай дураку в руки ... Ну ты понял