Re[39]: О сопровождении
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 21.06.07 13:06
Оценка: +1
Здравствуйте, WolfHound, Вы писали:

ГВ>>А меня, вот, обилие "может быть" в упомянутом постинге заставляет сомневаться в "конечности" этого результата.

WH>Просто сам факт использования таких структур говорит о многом.
WH>
WH>ID.
WH>Type (button, listbox, combobox, checkbox, radiobutton, edit и т.д.).
WH>Text.
WH>Picture.
WH>


Ни о чём он в данном случае не говорит. Озвученная Кириллом постановка задачи:

2. Визуальная. Отвечает за создание и визуализацию контролов (за цвет контрола, надпись на кнопочке или картинку).


Ладно, "цвета" здесь нет.

Заменяем button на GUID0, combobox на GUID1 и т.п. Теперь даже сам Байт не сможет сказать, что модель привязана к конкретным типам контролов. Ну а то, что где-то просто обязан храниться идентификатор типа конкретного контрола, надеюсь, и так понятно.

WH>А затычка там или нет это вопрос десятый.


К законченному решению, к описанию подхода и к наброску для дискуссии предъявляются разные требования, не правда ли?

WH>Человек либо всегда проектирует как следует либо всегда проектирует отвратно.


Можно встречный вопрос? Спасибо. А почему у тебя IAttachedXXXXX вынесены в отдельные интерфейсы? Почему ты не сделал просто список attached-свойств (событий, ...)? По крайней мере, пара интерфейсов благополучно бы исчезла.

WH>Я бы понял если бы он создал нормальный дизайн пусть не учитывая то о чем я не сказал. Но он изобразил редкостного уродца.


Я вот, в свою очередь, понял, что ты не удосужился толком объяснить ключевые моменты задачи, а вместо этого кинулся на показанный набросок как на готовое решение по детально расписанной постановке, попутно уличая оппонента во всех мылимых и немыслимых грехах.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[37]: Ой
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 21.06.07 13:18
Оценка:
Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>Пожалуй, соглашусь с мнением Геннадия Васильева и сочту [...]


Я поторопился с этим
Автор: Геннадий Васильев
Дата: 21.06.07
постингом.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[37]: О сопровождении
От: WolfHound  
Дата: 21.06.07 13:35
Оценка: +1
Здравствуйте, Кирилл Лебедев, Вы писали:

WH>>Основное требование а компоненте это связывание во время работы программы.

WH>>Есдинственный способ связать что-то с чем-то в сатически типизированном языке это интерфейсы.
КЛ>Разве эти интерфейсы относятся к компонентам?
Они относятся к их метаданным.
Но есть еще и код для обработчиков в форме. И он работает через интерфейсы конкретных контролов ибо они в зависимотсти от обстоятельств вполне могут иметь разные реализации.

КЛ>Мы ведь говорим о них, если Вы еще не забыли .


КЛ>Никакого динамического связывания тут не надо — Вы ведь сами писали, что у Вас имеется только одна их реализация.

А завтра будет 2. Так всегда бывает.

КЛ>А суть проблемы в том, что Вы наплодили 10 интерфейсов и еще 5 классов для их реализации. И к тому же не можете внятно объяснить, какой интерфейс за что у Вас отвечает.

А может просто ты не можешь понять?
Интерфейсы просты как пробка.
Каждый из них отвесает за свой кусок функционала.

КЛ> Говорите много "умных" слов про модели данных и метаданных. Но простая мысль о том, что не надо создавать класс (или интерфейс), у которого нет обязанностей, Вам почему-то в голову не приходит. А ведь именно об этом сказано в моей презентации.

А тебе не приходила в голову мысль что ты просто не можешь понять о чем я говорю?
А о том что я просто знаю больше методов структуирования системы?

КЛ>

    КЛ>
  1. Либо мысль про функциональную природу класса, изложенная в презентации, для Вас стара и банальна, и Вы ее хорошо понимаете. Но тогда Ваша модель — с точки зрения этой мысли — не выдерживает никакой критики, т.к. Вы не можете сформулировать обязанности приведенных интерфейсов.
    КЛ>
  2. Либо мысль, изложенная в презентации, для Вас нова, и Вы с ней не согласны. В этом случае Вы можете отстаивать свои интерфейсы. Но тогда утверждать, что в презентации для Вас не изложено ничего нового Вы не можете.
    КЛ>
А тебе не приходил в голову вариант что:
1)Я понимаю все что написано в презинтации.
2)Я понимаю ущербность такого подхода.
Ы?

КЛ>Ну вот при чем тут 6000 на 8000? Какое отношение это имеет к лэйаутам?

КЛ>Зачем вообще нужно хранить всю сетку? Почему нельзя указывать только целочисленные координаты контролов?
Зачем целочисленные?
Зачем привязка к пикселям?
Привязка к пикселям это анахренизм. Который тянется с тех времен когда компы были большими и медленными.
Современные ГУИ оперируют числами с плавующей точкой.
Посмотри на WPF(ГУИ нового поколения от мелкософт)
И они использую для расчетов double и совершенно правы ибо это даем массу возможностей.
Начиная с разлисных хитровывернутых лейаутов (типа такого http://www.codeproject.com/WPF/Panels.asp ) заканчивая возможностью перейти на устройства с большим разрешением.
И вобще сейчас придет McSeem2 и раскажет про линию толщиной в 1.3 пикселя.

КЛ>Извините, но Ваше сообщение выглядит, как неаргументированный поток сознания. Вы уж либо по-человечески все объясните, либо прекратите "выкрикивать шаманские заклинания и стучать в бубен".

А... ну-ну...

КЛ>Я уже писал, что неумение поставить и объяснить задачу фактически означает приговор для инженера.

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

КЛ>Пожалуй, соглашусь с мнением Геннадия Васильева и сочту, что Вы уклоняетесь от объяснений лишь для того, чтобы использовать мое незнание некоторых деталей (в силу того, что я не программирую на .NET) в качестве преимущества в споре.

Да причем тут .НЕТ?
Отвечу: Совершенно не причем.

КЛ>Похоже, Вы чувствуете, что объясни Вы все мне по-человечески, Ваш дизайн будет разбит в пух и прах, а предложенное решение — будет выглядеть проще и гораздо элегантнее.


Пока что все что тут было разбито в пух и прах это твои таблички...
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[40]: О сопровождении
От: WolfHound  
Дата: 21.06.07 13:52
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Заменяем button на GUID0, combobox на GUID1 и т.п. Теперь даже сам Байт не сможет сказать, что модель привязана к конкретным типам контролов. Ну а то, что где-то просто обязан храниться идентификатор типа конкретного контрола, надеюсь, и так понятно.

Ответь на простой вопрос: Зачем edit'у картинка?
У Кирилла не получилось. Может у тебя как его адвоката получится?
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[41]: О сопровождении
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 21.06.07 14:08
Оценка:
Здравствуйте, WolfHound, Вы писали:

ГВ>>Заменяем button на GUID0, combobox на GUID1 и т.п. Теперь даже сам Байт не сможет сказать, что модель привязана к конкретным типам контролов. Ну а то, что где-то просто обязан храниться идентификатор типа конкретного контрола, надеюсь, и так понятно.

WH>Ответь на простой вопрос: Зачем edit'у картинка?
WH>У Кирилла не получилось. Может у тебя как его адвоката получится?

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

Однако, конструктивного обсуждения пока не состоялось. Кстати, я проголосовал за отделение ветки.

А теперь ответь на мой вопрос: почему IAttachedXXXXX, а не контейнер attached-элементов?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[38]: О сопровождении
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 21.06.07 14:24
Оценка: +1
Здравствуйте, WolfHound, Вы писали:

КЛ>> Говорите много "умных" слов про модели данных и метаданных. Но простая мысль о том, что не надо создавать класс (или интерфейс), у которого нет обязанностей, Вам почему-то в голову не приходит. А ведь именно об этом сказано в моей презентации.

WH>А тебе не приходила в голову мысль что ты просто не можешь понять о чем я говорю?

Не знаю, как Кириллу, а мне приходит в голову, что ты не можешь толком по-человечески объяснить то, что сделал.

WH>А о том что я просто знаю больше методов структуирования системы?


И как называется метод структурирования системы, использованный тобой для получения показанного ранее набора интерфейсов?

[...]

КЛ>>Я уже писал, что неумение поставить и объяснить задачу фактически означает приговор для инженера.

WH>А тебе не кажется что тут проблема может быть не во мне, а в тебе?

Угу, то есть задачу описания структуры данных ты таки сформулировать или не можешь, или не хочешь. А также, почему-то не говоришь, что компонентная инфраструктура зачастую включает тот или иной стандарт на описание компонентов (ту самую "модель метаданных"). Ну ладно, я это сформулировал за тебя. Так где проблема-то получается?

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


WH>Мои решения направленны на упрощение развития системы.


Ты просто вытесняешь решение конкретных прикладных задач (о которых, в частности, говорит Кирилл) на уровень самих компонентов. Но это только часть решения задачи, например, построения редактора интерфейса. Конкретно — это только его API. Коих у одного редактора может быть вагон и маленькая телега.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[42]: О сопровождении
От: WolfHound  
Дата: 21.06.07 14:32
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Однако, конструктивного обсуждения пока не состоялось.

А его и не могло получиться ибо для этого Кириллу пришлось бы признать полную не состоятельность его концепции...

ГВ>Кстати, я проголосовал за отделение ветки.

Нет смысла.

ГВ>А теперь ответь на мой вопрос: почему IAttachedXXXXX, а не контейнер attached-элементов?

А это как?
Обрати внимание что у IProperty
object GetValue(object instance);

и у IAttachedProperty
object GetValue(object owner, object instance);

разные сигнатуры методов.

И ничего ты с этим не сделаешь.
Засовывать метаданные в объект нельзя ибо это разные сущьности.

Да и чем тебе эти интерфейсы помешали?
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[38]: О сопровождении
От: Кирилл Лебедев Россия http://askofen.blogspot.com/
Дата: 21.06.07 14:37
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Они относятся к их метаданным.

Это — шаманское заклинание! Оно никак не проясняет обязанности каждого конкретного интерфейса. Корректный ответ на вопрос должен строиться по такой схеме:

  1. Обязанностью интерфейса IElementBase является...
  2. Обязанностью интерфейса IEventBase является...
  3. И т.д. — для каждого интерфейса.

КЛ>>Никакого динамического связывания тут не надо — Вы ведь сами писали, что у Вас имеется только одна их реализация.

WH>А завтра будет 2. Так всегда бывает.

А зачем? Почему может появиться вторая реализация? Сколько может появиться таких реализаций вообще? Одна? Две? Три? Тридацать три?

Почему Вы решаете задачу, которой нет, а вот задачу унификации IProperty и IAttachedProperty и IEvent и IAttachedEvent, которая реально существует и актуальна, Вы не решаете? Подумать только, на том основании, что в методах IAttachedProperty на один параметр больше, Вы вместо одного интерфейса создали два? А если в дальнейшем потребуется ввести еще один параметр — создадите еще один интерфейс?

Зачем без необходимости плодить сущности?

КЛ>>А суть проблемы в том, что Вы наплодили 10 интерфейсов и еще 5 классов для их реализации. И к тому же не можете внятно объяснить, какой интерфейс за что у Вас отвечает.

WH>А может просто ты не можешь понять?
Тут уж несколько раз говорили: если читатель не понимает, то виноват автор — значит автор не смог объяснить.

WH>Интерфейсы просты как пробка.

WH>Каждый из них отвесает за свой кусок функционала.
Я не возвражаю. Просто почему-то Вы этот функционал скрываете. И у двух пар интерфейсов этот функционал совпадает.

WH>А тебе не приходила в голову мысль что ты просто не можешь понять о чем я говорю?

Вы уклонились от ответов на ряд ключевых вопросов, которые нужны для понимания. Что же Вы после этого хотите?

WH>А о том что я просто знаю больше методов структуирования системы?

Честно говоря, я в этом сомневаюсь. В течение дискуссии Вы продемонстрировали:

  1. Неспособность грамотно и понятно отвечать на вопросы собеседника, которые нужны для правильной постановки задачи.
  2. Множество способов ухода от ответов на эти вопросы: путем ссылки на то, что это займет много времени, что собеседник туп и не понимает и т.д.
  3. Различные нечестные приемы, чтобы переспорить собеседника, к числу которых можно отнести: постановку себя в позицию судьи или начальника, проводящего собеседование, неправильное обращение силлогизмов, бесконечный повтор эмоциональных и уничижительных оценок меня и моего решения без обоснования, оценка драфта решения по тем же критериям, по которым оценивается окончательное (релизное) решение и многое-многое другое.

Порядочные люди и грамотные специалисты так не поступают.

WH>А тебе не приходил в голову вариант что:

WH>1)Я понимаю все что написано в презинтации.
WH>2)Я понимаю ущербность такого подхода.
WH>Ы?

В таком случае Вы должно быть воююете сразу на два фронта: и со мной, и с классиками ООП. Мне ведь было сказано, что я не сказал ничего нового, и что все это описано у классиков ООП.

WH>Начиная с разлисных хитровывернутых лейаутов (типа такого http://www.codeproject.com/WPF/Panels.asp ) заканчивая возможностью перейти на устройства с большим разрешением.

WH>И вобще сейчас придет McSeem2 и раскажет про линию толщиной в 1.3 пикселя.
Вы не ответили ни на один вопрос по лэйаутам. Это не способствует прояснению и постановке задачи. В конце-концов, откуда я знаю, что лично Вы или .NET понимаете под лэйаутом. У меня при этом может быть совсем другое понимание, которое почерпнуто из опыта программирования под Win32 API. О каком решении задачи может идти речь, когда Вы, быть может, понимаете одно, а я — другое?

WH>А тебе не кажется что тут проблема может быть не во мне, а в тебе?

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

WH>Твои на то чтобы сею секунду налабать абы как и чтобы както работало... до первого изменения...


WH>Пока что все что тут было разбито в пух и прах это твои таблички...

Естественно. Ведь Вы описали одну задачу, а решение оценивали с точки зрения другой задачи — нехитрый прием для людей, которые не способны честно и предметно вести разговор.
С уважением,
Кирилл Лебедев
Software Design blog — http://askofen.blogspot.ru/
Re[39]: О сопровождении
От: WolfHound  
Дата: 21.06.07 14:49
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Не знаю, как Кириллу, а мне приходит в голову, что ты не можешь толком по-человечески объяснить то, что сделал.

Это читал?
Re[19]: ...продолжение
Автор: WolfHound
Дата: 23.05.07


ГВ>И как называется метод структурирования системы, использованный тобой для получения показанного ранее набора интерфейсов?

Я комбинирую множество различных стилей. Ибо разные задачи требуют разных решений.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[39]: О сопровождении
От: Кирилл Лебедев Россия http://askofen.blogspot.com/
Дата: 21.06.07 14:51
Оценка:
WH>>Пока что все что тут было разбито в пух и прах это твои таблички...
КЛ>Естественно. Ведь Вы описали одну задачу, а решение оценивали с точки зрения другой задачи — нехитрый прием для людей, которые не способны честно и предметно вести разговор.

Не смотря на то, что последнее мое сообщение получилось через чур эмоциональным, предлагаю вернуться к конструктивному обсуждению и решению задачи. Для этого мне хотелось бы получить от Вас ответы на такие вопросы:

  1. Каковы обязанности каждого интерфейса из приведенных десяти? В том числе, меня интересует интерфейс IType. О нем Вы почти ничего не писали.
  2. Почему Вы решили отделить IProperty от IAttachedProperty? Насколько различается реализация этих интерфейсов?
  3. Как используются приведенные Вами интерфейсы? Они где-то хранятся? В какой-то коллекции? Что это за коллекция? Или это чисто хэлперы для сериализации?
  4. Что Вы понимаете под лэйаутами? Почему Вы считаете грид-лэйаут сильно отличающимся от position layout? Как эти лэйауты работают? Не могли бы привести примеры?
  5. Как используется spline layout? В каких ситуациях выгодно использование именно этого layout'а?
  6. Какой интерфейс поддерживают лэйауты? В чем принципиальная разница между реализациями этого интерфейса для absolute position layout и spline layout? В чем там разница, кроме выравнивания по прямой и выравнивания по сплайну?
С уважением,
Кирилл Лебедев
Software Design blog — http://askofen.blogspot.ru/
Re[43]: О сопровождении
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 21.06.07 15:19
Оценка:
Здравствуйте, WolfHound, Вы писали:

ГВ>>Однако, конструктивного обсуждения пока не состоялось.

WH>А его и не могло получиться ибо для этого Кириллу пришлось бы признать полную не состоятельность его концепции...

ГВ>>Кстати, я проголосовал за отделение ветки.

WH>Нет смысла.
Я проголосовал — "за".

ГВ>>А теперь ответь на мой вопрос: почему IAttachedXXXXX, а не контейнер attached-элементов?

WH>А это как?
WH>Обрати внимание что у IProperty
WH>
WH>object GetValue(object instance);
WH>

WH>и у IAttachedProperty
WH>
WH>object GetValue(object owner, object instance);
WH>

WH>разные сигнатуры методов.

WH>И ничего ты с этим не сделаешь.

WH>Засовывать метаданные в объект нельзя ибо это разные сущьности.

Ну, перебираешь же ты их где-то? Не на воздусех же они висят?

Да и вообще — параметры owner и instance можно было бы замкнуть в самих экземплярах. Тогда сразу упростились бы и остальные интерфейсы. Примерно так:

    public interface IProperty : IPropertyBase
    {
        object GetValue();
        void SetValue(object value);
        void AddValueChanged(EventHandler handler);
        void RemoveValueChanged(EventHandler handler);
        bool CanResetValue();
        void ResetValue();
        bool ShouldSerializeValue();
    }

    public interface INativeProperty : IElementBase
    {
      IProperty RequestProperty(object instance);
    }

    public interface IAttachedProperty : IElementBase
    {
      IProperty RequestProperty(object owner, object instance);
    }


Аналогично, ИМХО, стоило бы поступить и с IxxxxxEvent-интерфесами.

Обрати внимание, что здесь IProperty — это уже просто свойство, которое скрывает экземпляр и владельца. Кроме того, названия INativeProperty и IAttachedProperty содержат характеристику метода дальнейшей работы с экземпляром IProperty.

Кстати, почему CanRead/CanWrite не продублированы по отношению к экземпляру-носителю свойства? У тебя не бывает такого, что какой-то элемент объявляется read-only в процессе редактирвоания?

WH>Да и чем тебе эти интерфейсы помешали?


Пышностью.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[40]: О сопровождении
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 21.06.07 15:40
Оценка:
Здравствуйте, WolfHound, Вы писали:

ГВ>>Не знаю, как Кириллу, а мне приходит в голову, что ты не можешь толком по-человечески объяснить то, что сделал.

WH>Это читал?
WH>Re[19]: ...продолжение
Автор: WolfHound
Дата: 23.05.07


Естественно. Тебя потом переспросили о самой задаче (а не о подходе к её решению, каковым являются "собственные и присоединённые свойства") и понеслась... Короче говоря, извини, но общее впечатление всё равно именно таково, как я о нём написал.

ГВ>>И как называется метод структурирования системы, использованный тобой для получения показанного ранее набора интерфейсов?

WH>Я комбинирую множество различных стилей. Ибо разные задачи требуют разных решений.

Так как же называется "метод структурирования системы"?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[39]: О сопровождении
От: WolfHound  
Дата: 21.06.07 15:46
Оценка:
Здравствуйте, Кирилл Лебедев, Вы писали:

WH>>Они относятся к их метаданным.

КЛ>Это — шаманское заклинание! Оно никак не проясняет обязанности каждого конкретного интерфейса. Корректный ответ на вопрос должен строиться по такой схеме:
Интерфейсы IProperty, IEvent, IAttachedProperty, IAttachedEvent являются описателями конкретных элементов объекта.
Их обязанности предоставлять обощенный доступ к конкретным элементам объекта.
Интерфейсы IElementBase, IEventBase, IPropertyBase, IAttachedElement, IElement отвечают за обобщенную работу с группами элементов объекта.

КЛ>А зачем? Почему может появиться вторая реализация? Сколько может появиться таких реализаций вообще? Одна? Две? Три? Тридацать три?

Сколько угодно.
Таковы реалии.
И чем болие библиотечный код тем больше вероятность того что будут нужны альтернативные реализаци.
В данном случае у нас весьма фундаментальная система.
Скажем если я захочу написать контрол на немерле то есть вероятность близкая к 1 что метаданные и кучу деталий реализации будут генерить макросы.
И иметь интерфейсы в данном случае необходимо ибо иначе мне придется удалять гланды через зад автогеном.

КЛ>Почему Вы решаете задачу, которой нет, а вот задачу унификации IProperty и IAttachedProperty и IEvent и IAttachedEvent, которая реально существует и актуальна, Вы не решаете? Подумать только, на том основании, что в методах IAttachedProperty на один параметр больше, Вы вместо одного интерфейса создали два?

Нет. Я их не объеденяю на основании того что это разные сущьности.
А вот откуда взялась необходимость их объеденения это вопрос к тебе.

КЛ>А если в дальнейшем потребуется ввести еще один параметр — создадите еще один интерфейс?

А зачем?
Давай конкретно.
Что еще нужно добавить в модель метаданных?

КЛ>Зачем без необходимости плодить сущности?

Зачем сливать в одну сущьность различные сущьности?

WH>>А может просто ты не можешь понять?

КЛ>Тут уж несколько раз говорили: если читатель не понимает, то виноват автор — значит автор не смог объяснить.
Правда? Очень интересная теория. Только к жизни отношения не имеет.

КЛ>Я не возвражаю. Просто почему-то Вы этот функционал скрываете.

Не скрываю.
Я уже несколько раз говорил что к чему.

КЛ>И у двух пар интерфейсов этот функционал совпадает.

Не совпадает.

КЛ>Вы уклонились от ответов на ряд ключевых вопросов, которые нужны для понимания. Что же Вы после этого хотите?

Каких?

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

Это ты про вопросы типа: Перечисли проблемы интеграции win с web?

КЛ>В таком случае Вы должно быть воююете сразу на два фронта: и со мной, и с классиками ООП. Мне ведь было сказано, что я не сказал ничего нового, и что все это описано у классиков ООП.

Авторитеты не имеют значения.
Лишь конкретные идеи имеют значение.

КЛ>Вы не ответили ни на один вопрос по лэйаутам.

Да я только и делаю что отвечаю.
А то что ты изобрел и зациклился на сеточных лейаутах (которых есть всего один) это ИМХО не моя проблема.

КЛ>Это не способствует прояснению и постановке задачи. В конце-концов, откуда я знаю, что лично Вы или .NET понимаете под лэйаутом.

Я тебе уже 100 раз говорил.
Это объект который отвечает за расположение и размер контролов.

КЛ>У меня при этом может быть совсем другое понимание, которое почерпнуто из опыта программирования под Win32 API.

В WinAPI есть всего один убогий лейаут.

WH>>Пока что все что тут было разбито в пух и прах это твои таблички...

КЛ>Естественно. Ведь Вы описали одну задачу, а решение оценивали с точки зрения другой задачи — нехитрый прием для людей, которые не способны честно и предметно вести разговор.
Я оценивал то что оценивал.
Я оценил конкретное решение.
Если бы твое решние не рассыпалось при малейшей критеке я бы уточнил детали.
Но я увидил решение которое является образцом ужасной архитектуры. И я не верю в то что один и тот же человек будет по разному проектировать прототипы и законченные решения.
Ибо оно не выдерживает никаких изменений.
Там полностью отсутствует инкапсуляция.
Те все контролы видят внутренности всех контролов.
К нему невозможно подключать контролы без модификации кода. Те Вася Пупкин не сможет написать свой контрол.
...
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[44]: О сопровождении
От: WolfHound  
Дата: 21.06.07 16:02
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Ну, перебираешь же ты их где-то? Не на воздусех же они висят?

Получаю по System.Type объект IType, беру из него коллекцию интересующих меня элементов и вперед.

ГВ>Да и вообще — параметры owner и instance можно было бы замкнуть в самих экземплярах. Тогда сразу упростились бы и остальные интерфейсы. Примерно так:

1) Нет имеет смысла.
2) Ты в серьез на каждый объект предлагаешь создать еще десяток? Причем совершенно на пустом месте.

ГВ>Кстати, почему CanRead/CanWrite не продублированы по отношению к экземпляру-носителю свойства? У тебя не бывает такого, что какой-то элемент объявляется read-only в процессе редактирвоания?

Такой функциональности нет и в .NET'ных свойствах...

WH>>Да и чем тебе эти интерфейсы помешали?

ГВ>Пышностью.
Очень конструктивно
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[44]: О сопровождении
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 21.06.07 16:06
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Да и вообще — параметры owner и instance можно было бы замкнуть в самих экземплярах.


Нельзя. В таком раскладе вместо сравнительно небольшого и кешируемого дерева метаданных придется на каждую форму строить их развесистое дерево. Вобщем, тот самый случай, когда state лучше вынести наружу.
... << RSDN@Home 1.2.0 alpha rev. 688>>
AVK Blog
Re[45]: О сопровождении
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 21.06.07 16:19
Оценка:
Здравствуйте, WolfHound, Вы писали:

ГВ>>Да и вообще — параметры owner и instance можно было бы замкнуть в самих экземплярах. Тогда сразу упростились бы и остальные интерфейсы. Примерно так:

WH>1) Нет имеет смысла.

Упрощается клиенсткий код, ИМХО.

WH>2) Ты в серьез на каждый объект предлагаешь создать еще десяток? Причем совершенно на пустом месте.


Почему на пустом месте? В данном случае интерфейсы INative/IAttached отвечают только за "работу" объекта в контейнере и за создание экземпляра, реализующего IProperty для работы с конкретными объектами.

ГВ>>Кстати, почему CanRead/CanWrite не продублированы по отношению к экземпляру-носителю свойства? У тебя не бывает такого, что какой-то элемент объявляется read-only в процессе редактирвоания?

WH>Такой функциональности нет и в .NET'ных свойствах...

Ну мы же не .Net-ные свойства обсуждем, верно?

WH>>>Да и чем тебе эти интерфейсы помешали?

ГВ>>Пышностью.
WH>Очень конструктивно

Это эстетический критерий, под которым лежат вполне реальные основания: зачем вводить дополнительный параметр во все методы интерфейса, когда его можно упрятать внутрь, в реализацию? А заодно упростить унифицированную обработку значений свойств.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[45]: О сопровождении
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 21.06.07 16:43
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Геннадий Васильев, Вы писали:


ГВ>>Да и вообще — параметры owner и instance можно было бы замкнуть в самих экземплярах.


AVK>Нельзя. В таком раскладе вместо сравнительно небольшого и кешируемого дерева метаданных придется на каждую форму строить их развесистое дерево. Вобщем, тот самый случай, когда state лучше вынести наружу.


Возможно. Хотя, ИМХО, экземпляры можно создавать непосредственно перед использованием. Да и, собственно, никто не мешает реализовать свойства примерно так:

public class NativePropertyImpl : IAttachedProperty, IProperty {...}
public class NativePropertyImpl : INativeProperty, IProperty {...}


Тогда и накладные расходы на перезапрос интерфейса IProperty будут минимальными. В любом случае, пользователю хорошо известно, с каким объектом он собирается работать — Native или Attached.

С другой стороны, stateless-дизайн можно ещё оправдать тем, что ситуация с выполнением многочисленных одинаковых операций для свойств разных объектов (например, SetValue для всех контролов) встречается чаще, чем вызов разных методов для одного объекта (например, последовательность CanReset/Reset/GetValue или что-то в этом роде). Но я бы тут подумал, что в конечном итоге лучше — быстро создавать объект или передавать один-два дополнительных параметра.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[46]: Отбой
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 21.06.07 16:46
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>
ГВ>public class AttachedPropertyImpl : IAttachedProperty, IProperty {...}
ГВ>public class NativePropertyImpl : INativeProperty, IProperty {...}
ГВ>


Что-то я зарапортовался малость. Нельзя их так реализовывать. Соответственно, снизить накладные расходы тоже не получится.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[40]: О сопровождении
От: WolfHound  
Дата: 21.06.07 16:54
Оценка:
Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>1)Каковы обязанности каждого интерфейса из приведенных десяти? В том числе, меня интересует интерфейс IType. О нем Вы почти ничего не писали.

IType — Описатель типа. Хранит коолекцию элементов. И коллекцию базовых типов.
IDomain — Хранит отображение System.Type в IType. Необходим для работы с разными реализациями. Например win и web.

Интерфейсы IProperty, IEvent, IAttachedProperty, IAttachedEvent являются описателями конкретных элементов объекта.
Их обязанности предоставлять обощенный доступ к конкретным элементам объекта.
Интерфейсы IElementBase, IEventBase, IPropertyBase, IAttachedElement, IElement отвечают за обобщенную работу с группами элементов объекта.

КЛ>2)Почему Вы решили отделить IProperty от IAttachedProperty? Насколько различается реализация этих интерфейсов?

По тому что это различные сущьности.
IProperty — Собственное свойство объекта.
IAttachedProperty — Свойство которое данный объект прицепляет к другому.
С событиями аналогично.

КЛ>3)Как используются приведенные Вами интерфейсы? Они где-то хранятся? В какой-то коллекции? Что это за коллекция? Или это чисто хэлперы для сериализации?

См пункт 1

КЛ>4)Что Вы понимаете под лэйаутами?

Объект который отвечает за положение, размер и ориентацию вложеных объектов.

КЛ>Почему Вы считаете грид-лэйаут сильно отличающимся от position layout? Как эти лэйауты работают? Не могли бы привести примеры?

Во первых: это разные лейауты. А мешать теплое с мягким нельзя.
Во вторых: сейчас есть вполне логичная тенденция отказываться от привязки к пикселям. Те все новые системы ГУМ используют плавующею точку. Мелкософт в своем WPF использует double.

КЛ>5)Как используется spline layout? В каких ситуациях выгодно использование именно этого layout'а?

Например если пользователь захочет расположить картинки вдоль какойто кривой.
Как вариант можно еще сюда посмотреть http://www.codeproject.com/WPF/Panels.asp тут же можно посмотреть на один из вариантов обсчета лейаутов.
Вобще можно придумать много разных лейаутов.

КЛ>6)Какой интерфейс поддерживают лэйауты?

interface IControlContainer
{
    IControlCollection Controls { get; }
}


КЛ>В чем принципиальная разница между реализациями этого интерфейса для absolute position layout и spline layout?

Этого ни в чем. В принципе при реализации (интерфейс никто не отменял) тут даже можно воспользоваться наследованием (реализации) чтобы не дублировать код, а можно и не воспользоваться... в этом и есть прелесть интерфейсов.
Но у них есть свои интерфейсы.
position layout — содержит присоедененные свойства для задания позиции и размеров.
spline layout — содержит коллекцию опорных точек сплайна.

КЛ>В чем там разница, кроме выравнивания по прямой и выравнивания по сплайну?

position layout — не занимается выравниванием. Он четко забивает позицию и размеры.

ЗЫ Не пользуйся тегом list его не удобно комментировать.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[46]: О сопровождении
От: WolfHound  
Дата: 21.06.07 17:04
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Упрощается клиенсткий код, ИМХО.

Ни разу не упрощается.
К тому же клиенты этой модели сериалайзеры и дизайнеры.

ГВ>Почему на пустом месте? В данном случае интерфейсы INative/IAttached отвечают только за "работу" объекта в контейнере и за создание экземпляра, реализующего IProperty для работы с конкретными объектами.

Ну по тому что оно ничего не дает, а накладных расходов добавляет.

ГВ>Ну мы же не .Net-ные свойства обсуждем, верно?

Всеравно не вижу смысла.

ГВ>Это эстетический критерий, под которым лежат вполне реальные основания: зачем вводить дополнительный параметр во все методы интерфейса, когда его можно упрятать внутрь, в реализацию?

И превратить stateless в statefull?
Ты уверен что оно того стоит?

ГВ>А заодно упростить унифицированную обработку значений свойств.

Не упростит.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.