Re[55]: О сопровождении
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 28.06.07 08:12
Оценка: 16 (1)
Несколько поправок

AVK>1) Создается экземпляр сервиса для работы с метаданными


Не создается, а запрашивается у service provider.

AVK>8) Для каждого из элементов получаем список возможных владельцев (для собственных свойств в качестве владельца возвращается указатель на сам элемент)


Следует читать "на сам компонент".

AVK>14) Если интерцептор есть и подтвердил то, что он хочет перехватить, то перекладываем задачу получения значения свойства на него.


Интерцепторы нужны для работы со свойствами вроде Visible или Enabled в редакторе.

AVK>17) Если для свойства есть кастомный сериализатор, то получаем экземпляр сериализатора и предлагаем ему записать свойство из контекста в МСП

AVK>18) Если значение свойства является компонентом, то проверяем, несет ли ответственность владелец свойства за создание этого компонента.

П.18 выполняется, если не выполняется условие в п.17.

AVK>26) Если ни одна из проверок свойства не вернула true


Имеются ввиду проверки в п.17, п.18, п.21
... << RSDN@Home 1.2.0 alpha rev. 688>>
AVK Blog
Re[48]: О сопровождении
От: Кирилл Лебедев Россия http://askofen.blogspot.com/
Дата: 28.06.07 09:15
Оценка:
Здравствуйте, WolfHound, Вы писали:

КЛ>>Сложность никуда не выносят. Ее устраняют при помощи модели.

WH>Нет. Сложность устранить нельзя.
Вы это не доказали.

WH>Ее можно перенести на другой уровень но не устранить.

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

WH>Модель римских чисел примитивна.

Вы ошибаетесь. Например, вавилонская шестидесятиричная система счисления была хуже римской из-за того, что для обозначения, например, числа 5 нужно было рисовать пять колышков. Греческая система была хуже из-за обилия цифр (все символы греческого алфавита). А римские цифры хороши своей экономичностью. Смотрите сами: IV — это четыре, а VI — это шесть. Идея, когда от положения цифры (до или после), зависит число (т.е. цифра либо вычитается либо прибавляется) была нетривиальной.

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

WH>Там есть только конкретные числа.

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

КЛ>>Мягко говоря, это не так. В римской системе зарезервированы знаки для чисел: 1 (I), 5 (V), 10 (X), 50 (L), 100 (C), 1000 (M — что ли?). Остальные числа получаются путем добавления цифр слева или справа. В некотором роде, римскую систему счисления тоже можно назвать позиционной.

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

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

Так вид числа как раз-таки и зависит от модели.

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

WH>Это не важно.
WH>Относительная стоимость реализации тем ниже чем чаще она используется.
Без изобретения позиционной системы с фиксированным основанием не было бы и компьютера. Так что реализацию все равно придется писать. Вот напишите, и мы сравним сложность.

WH>Если оно написано один раз, имеет простой, четкий, понятный интерфейс и работает то нет.

Не играет роли — реализация все равно нужна. Так что — реализацию в студию.

WH>Так я о том и говорю. Сложность ни куда и ни когда не девается.

WH>Она только перераспределяется.
WH>Причем перераспределяя сложность можно упрощать конкретное решение за счет того что сложность загнана на болие низкий уровень и спрятана простым интерфейсом.
Это Вы так хотели сделать — так и сделали. Но ничего этим не доказали. Потому что не привели реализацию.
Теперь настало время ее привести. Напомню условие: нельзя использовать позиционную систему счисления с фиксированным основанием.

WH>Конвеер (без перенастройки) может выпускать только совершенно идентичные изделия.

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

WH>Я говорил о принципе.

WH>Те принцип колеса это фундамент, а создание конкретного колеса это уже детали.
Конвеер контролов тоже не изобретает никаких контролов. Он просто их воспроизводит в определенной последовательности.
Такое возможно, потому что во множестве контролов заключено конечное (и весьма небольшое!) число принципов.

WH>>>Да обсудить и утвердить общею концепцию системы нужно. Но проектировать толпой народа кнопку... это мягко говоря перебор.

КЛ>>Тут Вы лукавите — как-то вдруг забыли про сложные контролы.
WH>А именно? Самый сложный контрол это VirtualTreeGrid ничего сложеней нет.
В таком случае, конвеер — это то, что доктор прописал. Раз нет ничего сложнее...

WH>Если ты конечно не собрался MSWord написать.

Не собирался. Об этом-то и говорил.

WH>Только саму программу дроблю на болие мелкие абстракции.

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

WH>А ты можешь также просто написать алгоритм который также хорошо паралелится?

WH>Причем паралелится совершенно прозрачно для клиентского кода.
Могу. Но пиписьками мериться не буду. Не в том возрасте.

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

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

КЛ>>А возможность написания контрола, который добавляет тултипы ко всем другим контролам на форме — это не лишняя связь?

WH>Нет. Лишняя связь это добавление тултипов непосредственно в контролы.
Так у Вас связь осталась. Просто она не задекларирована. Соответственно, как выражаются Ваши коллеги, контракт раздут...

КЛ>>И в жестком виде дублирует код большинства других контролов.

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

КЛ>>Если контролам не нужно знать, кто их размещает, то почему Вы эти свойства приаттачиваете к ним? Уж либо они не знают (и тогда свойства не прикрепляются), либо знают (и тогда свойства прикрепляются).

WH>Эти свойства сами по себе смысла не имеют.
WH>Они имеют смысл только когда они привязаны к конктретному контролу.
WH>Те в случае с GridLayout свойства Col и Row без привязки к конкретному контролу не имеют смысла.
WH>Но контролу о них знать не нужно ибо в разных ситуациях к нему могут быть привязыны разные свойства.
WH>Ибо если мы этот контрол перетащим скажем на PositionLayout то свойства Col и Row потеряют смысл но понадобятся свойства Top, Left, Bottom, Right.
Тем не менее Вы все равно прикрепляете эти взаимосвязи к контролу (т.е. вставляете в него, пусть и в виде добавленных свойств). Гораздо выгоднее держать внешние взаимосвязи в отдельном объекте или хранилище, как, собственно говоря, я и предлагал. Прикреплять ничего не надо, а связи хранятся и редактируются.
С уважением,
Кирилл Лебедев
Software Design blog — http://askofen.blogspot.ru/
Re[49]: О сопровождении
От: WolfHound  
Дата: 28.06.07 12:16
Оценка:
Здравствуйте, Кирилл Лебедев, Вы писали:

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

Нет. Это свидетельствует о том что ты не способен выделять абстракции.
Ты в очередной раз зациклился на деталях реализации пропустив суть.
По простому это называется: За деревьями не видишь леса.

КЛ>Без изобретения позиционной системы с фиксированным основанием не было бы и компьютера.

Это мягко говоря не доказуемо.

КЛ>Так что реализацию все равно придется писать. Вот напишите, и мы сравним сложность.

Один раз.
Это главное.

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

WH>>Если оно написано один раз, имеет простой, четкий, понятный интерфейс и работает то нет.

КЛ>Не играет роли — реализация все равно нужна. Так что — реализацию в студию.
Но ее нужно написать один раз.
А использовать можно сколько угодно раз.

КЛ>А кто сказал, что контролы не являются идентичными изделиями? Если между ними и есть различия, то их можно свести к параметрам — так, что конвеер не придется перенастраивать.

Если ты про надпись на кнопке то да.
Если ты про создание собственно кнопки, едита, итп то нет.

КЛ>Конвеер контролов тоже не изобретает никаких контролов. Он просто их воспроизводит в определенной последовательности.

КЛ>Такое возможно, потому что во множестве контролов заключено конечное (и весьма небольшое!) число принципов.
Если ты каждую кнопку пишешь с нуля то да иначе нет.

WH>>А именно? Самый сложный контрол это VirtualTreeGrid ничего сложеней нет.

КЛ>В таком случае, конвеер — это то, что доктор прописал. Раз нет ничего сложнее...
Зачем конвеер для того чтобы создать:
1)Одну кнопку.
2)Один едит.
3)Один image.
4)Один VirtualTreeGrid.

Основная мысль в том что контрол пишется ровно один раз.
Причем пишется так чтобы не пересекаться по решаемым задачам с другими контролами.

Вернее так:
Один раз создается и фиксируется интерфейс. Без каких либо завязок на платформу.
И делается одна реализация на каждую платформу. Ибо сделать одну реализацию для win и web просто не возможно.
Там даже маловероятно наличие общего кода ибо платформы фундаментально различны.
Кроме сериалайзеров и тп ибо они полностью абстрагированны от контролов при помощи метаданных те работают с объектами вобще и контролами в частности исключительно через строгий интерфейс. В данном случае набор интерфейсов который ты никак не можешь/не хочешь понять.

КЛ>Вот об этом-то и речь: чтобы сгруппировать нечто сложное, нужно его сначала раздробить.

КЛ>Тот же принцип можно применить и к контролам.
Нет. Нужно выделить основные абстракции.
А выделение абстракций автоматически приводит к разделению кода.
Причем к очень строгому разделению ибо строгие интерфейсы (контролируемые компилятором) не дают реализациям цеплятся друг за друга.
Таким образом мы может менять (включая менять во время исполнения) реализации не трогая клиентский код.

WH>>А ты можешь также просто написать алгоритм который также хорошо паралелится?

WH>>Причем паралелится совершенно прозрачно для клиентского кода.
КЛ>Могу. Но пиписьками мериться не буду. Не в том возрасте.
Слив засчитан.
Эта задача не решается без выделения абстракций потока и фильтра. (названия могут быть другие но суть от этого не изменится)

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

КЛ>Как раз-таки очень хорошо понимаю. И описываю проблемы полиморфных программ со знанием дела.

Так ты ни одной не описал.
Вренне все твои описания идут от не правильно написанных программ в которых пытались очень криво использовать полиморфизм.
А именно там нигде не прослеживается выделение строгих и минимальных интерфейсов.
Без этого любые попытки писать полиморфный код обречены на полный провал.
Что у тебя собственно и прослеживается. (Взять хотябы твое решение дать всем контролам картинки и текст...)
Те все твои проблемы с полиморфизмом идут от его полного не понимания.

КЛ>Тем более, что Ваш добавляльщик тултипов — из той же серии...

Из какой?

КЛ>Так у Вас связь осталась. Просто она не задекларирована. Соответственно, как выражаются Ваши коллеги, контракт раздут...

Никуда он не раздут.
Контролы не знают о том что к ним цепляют тултипы.
Болие того есть масса способов чтобы и не узнали даже на уровне реализации...

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

Где?
Нет таких мест.
Каждый интерфейс делает ровно то что должен.
И ни один другой не повторяет функциональность.

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

Прикрипление исключительно логическое.
Для прикрипления и работы с прикрепленными свойствами есть строгий интерфейс.
Как это реализованно значения не имеет.
Есть множество вариантов:
1)Глобальное хранилище. (Как по мне бред полный. Куча проблем и никаких плюсов.)
2)Каждый объект который цепляет свойства к другим объектам хранит у себя словарик (объект -> набор присоедененных свойств).
3)Каждый объект хранит у себя словарик (ключ присоедененного свойства (у нас всеравно есть метаданные ) -> значение присоедененного свойства). Доступ к этому словарику происходит на уровне некого интерфейса специфичного для конкретной реализации.
...тут еще очень много вариантов...

Когда я это делал был выбран второй вариант.
Сейчас мне больше нравится третий ибо несколько проще реализовать.

Но это все детали реализации.
Они важны на уровне реализации и только на уровне реализации контролов.

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

AVK>10) Если элемент — событие...

AVK>11) Если сериализация требуется...
AVK>13) Если в п.10 имеем не событие, а свойство...
AVK>14) Если интерцептор есть и подтвердил то, что он хочет перехватить, то...
AVK>15) Если нет, то...
AVK>16) Если сериализация требуется, то...
AVK>17) Если для свойства есть кастомный сериализатор, то...
AVK>18) Если значение свойства является компонентом, то...
AVK>19) Если нет — ...
AVK>20) Если да — ...
AVK>21) Если свойство является коллекцией (реализует IEnumerable), то...
AVK>22) Для каждого элемента проверяем, является ли он компонентом
AVK>23) Если да, то...
AVK>24) Если нет, то...
AVK>26) Если ни одна из проверок свойства не вернула true, то...

Итого получается 14 проверок. Поэтому и sequence-диаграмма будет сложной. И код метода тоже сложный. Его, можно упростить, если:

1) Сгруппировать однородные проверки в функции.

Посмотрите, у Вас шаг 16 совпадает с шагом 11. И там, и там проверяется, нужна ли сериализация. Только в одном случае — для события, а в другом — для свойства.

AVK>11) Если сериализация требуется...

AVK>16) Если сериализация требуется, то...

2) Устранить различия между разными объектами на верхнем уровне.

Например, значение свойства может быть:

1) Простым типом данных.
2) Компонентом.
3) Коллекцией.

Почему бы эти различия не скрыть внутри функции Сериализовать Свойство?
С уважением,
Кирилл Лебедев
Software Design blog — http://askofen.blogspot.ru/
Re[56]: О сопровождении
От: WolfHound  
Дата: 28.06.07 14:12
Оценка:
Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>Почему бы эти различия не скрыть внутри функции Сериализовать Свойство?

Объясни пожалуйста как из того что написал Андрей следует что все это в одной функции?
Я не понимаю ход мыслей.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[56]: О сопровождении
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 28.06.07 14:20
Оценка:
Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>1) Сгруппировать однородные проверки в функции.


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

КЛ>2) Устранить различия между разными объектами на верхнем уровне.


IsSerializable и так принадлежит базовому интерфейсу и для свойства и для метода.

КЛ>Например, значение свойства может быть:


КЛ>1) Простым типом данных.

КЛ>2) Компонентом.
КЛ>3) Коллекцией.

КЛ>Почему бы эти различия не скрыть внутри функции Сериализовать Свойство?


Ты там прочел в начале, что подробности реализации опущены? Оно в реальном коде и есть одна функция SerializeProperty. Здесь я описал последовательность вызовов, а не структуру функций.
... << RSDN@Home 1.2.0 alpha rev. 688>>
AVK Blog
Re[50]: О сопровождении
От: Кирилл Лебедев Россия http://askofen.blogspot.com/
Дата: 28.06.07 15:06
Оценка:
Здравствуйте, WolfHound, Вы писали:

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

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

WH>Ты в очередной раз зациклился на деталях реализации пропустив суть.

WH>По простому это называется: За деревьями не видишь леса.
В реализации — в данном конкретном случае — и состоит суть. Потому что алгоритм писать надо. И сопровождать его тоже надо.

В Вашей модели (с римскими цифрами) все хорошо. Одно отсутствует — реализация. И поэтому модель бесполезна.

КЛ>>Без изобретения позиционной системы с фиксированным основанием не было бы и компьютера.

WH>Это мягко говоря не доказуемо.
Компьютер работает с двоичной системой счисления, а двоичная система счисления — это позиционная система с основанием 2.

WH>Дело в том что дорогая реализация написанная один раз и используемая миллион раз через простой интрефейс гораздо дешевле чем дешовая реализация написанная миллион раз по месту.

Это неважно. У Вас нет никакой.

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

Ваши подсчеты будут бесполезны, т.к. у Вас нет реализации.

WH>Но ее нужно написать один раз.

WH>А использовать можно сколько угодно раз.
Неважно — реализация-то у Вас отсутствует.

WH>Зачем конвеер для того чтобы создать:

WH>1)Одну кнопку.
WH>2)Один едит.
WH>3)Один image.
WH>4)Один VirtualTreeGrid.
Если у Вас всего 4 контрола, то Вам не нужен и компонентный подход.

КЛ>>Тем более, что Ваш добавляльщик тултипов — из той же серии...

WH>Из какой?
Из серии запутанного кода...

КЛ>>Так у Вас связь осталась. Просто она не задекларирована. Соответственно, как выражаются Ваши коллеги, контракт раздут...

WH> Никуда он не раздут.
WH>Контролы не знают о том что к ним цепляют тултипы.
Да, и сопровождающий программист тоже не знает. Никто не знает, а тултипы добавляются. Вот и не задекларированная связь!

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

WH>Где?
WH>Нет таких мест.
WH>Каждый интерфейс делает ровно то что должен.
WH>И ни один другой не повторяет функциональность.
Мне этот диалог напоминает хождение по кругу:
— Сильно ли различается код, использующий интерфейсы IProperty и IAttachedProperty?
— Нет, не сильно.
— В чем заключается различие?
— В случае IAttachedProperty добавляется еще один объект?
— Нельзя ли унифицировать интерфейсы и вместо двух из них оставить один?
— Нет, нельзя.
— Почему?
— Для attached нужно получить еще один объект.
— Нельзя ли инкапсулировать получение этого объекта?
— Нет, нельзя.
— Почему?
— Потому что это разные сущности.
— Почему сущности разные?
— Потому что разные
— Разве код использования этих сущностей не одинаковый?
— Нет разный.
— В чем различие?
— В дополнительном объекте.
— Нельзя ли его инкапсулировать?
— И т.д. по кругу.

Вы уж определитесь все-таки — разные или не разные? И если разные, то в чем состоит различие?

Совсем уж разжевываю: Нельзя ли добавить в методы IProperty еще один параметр, и сделать интерфейс полностью похожим на IAttachedProperty? Затем — убрать IAttachedProperty и использовать в обоих случаях IProperty. Только в случае, если свойство не прикрепленное, а свое, в качестве первого параметра передается null.

Можно ли будет в этом случае унифицировать вызывающий код и использовать его для обоих (attached и не-attached) случаев? Если нельзя, то почему?
С уважением,
Кирилл Лебедев
Software Design blog — http://askofen.blogspot.ru/
Re[57]: О сопровождении
От: Кирилл Лебедев Россия http://askofen.blogspot.com/
Дата: 28.06.07 15:11
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Объясни пожалуйста как из того что написал Андрей следует что все это в одной функции?

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

Сериализовать Дерево
1) ...
2) ...
3) Сериализовать Свойство

Сериализовать Свойство
1) ...
2) ...
3) ...

ИМХО, проще для понимания.
С уважением,
Кирилл Лебедев
Software Design blog — http://askofen.blogspot.ru/
Re[57]: О сопровождении
От: Кирилл Лебедев Россия http://askofen.blogspot.com/
Дата: 28.06.07 15:12
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Там всего одна проверка и ее так просто сгруппировать не получится, потому что последовательность проверок в случае свойств и событий разная. В свойстве есть интерцептор и его надо обязательно проверять до проверки сериализуемости.

А что такое интерцептор? В чем заключается его функция?
С уважением,
Кирилл Лебедев
Software Design blog — http://askofen.blogspot.ru/
Re[51]: О сопровождении
От: WolfHound  
Дата: 28.06.07 15:54
Оценка:
Здравствуйте, Кирилл Лебедев, Вы писали:

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

Из чего это следует?
Уж не из того ли что я не бросил все и не побежал этим заниматься?

КЛ>В Вашей модели (с римскими цифрами) все хорошо. Одно отсутствует — реализация. И поэтому модель бесполезна.

Модель ничего не знает о том что там за числа.
Она знает что есть числа и что их можно складывать, умножать и тп.
А римские они или нет это не важно.

WH>>Дело в том что дорогая реализация написанная один раз и используемая миллион раз через простой интрефейс гораздо дешевле чем дешовая реализация написанная миллион раз по месту.

КЛ>Это неважно. У Вас нет никакой.
Не важно.
Понадобится будет.
А так как это мне
а)Не интересно
б)Мне за это никто не заплатит
Я это писать не буду.

КЛ>Компьютер работает с двоичной системой счисления, а двоичная система счисления — это позиционная система с основанием 2.

Те невозможно построить комп на римских чиселках?
Сильно.
Я подозревал что с пониманием предмета тяжело но что до такой степени...

КЛ>Если у Вас всего 4 контрола, то Вам не нужен и компонентный подход.

1)Откуда следует что у меня только 4 контрола?
2)Почему мне не нужен компонентный подход если он облегчает жизнь даже в случае если контрол только один?
Жизнь он облегчает тем что формализует контракты и не дает зацеписаться за детали реализации.
Что значительно упрощает поддержку и развитие.

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

Я уже говорил что это задокументированно:
1)В описании объектной системы.
2)В описании контрола.
Но чукча похоже не читатель...

КЛ>Можно ли будет в этом случае унифицировать вызывающий код и использовать его для обоих (attached и не-attached) случаев?

Нельзя.

КЛ>Если нельзя, то почему?

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

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

WH>Из чего это следует?
Из того, что Вы приводите тезисы и не берете на себя труд доказательства.

WH>Уж не из того ли что я не бросил все и не побежал этим заниматься?

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

WH>Модель ничего не знает о том что там за числа.

Это неважно — задача была про римские цифры.

WH>Она знает что есть числа и что их можно складывать, умножать и тп.

Нужно было рассмотреть только умножение.

WH>А римские они или нет это не важно.

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

Да что там алгоритма! Я просил просто перемножить два конкретных числа! Вы и этого не сделали!

Итак, что же мы имеем на выходе? Вы построили суперабстрактную, но не работающую модель. Почему не работающую? Потому что нет ни одной реализации, которая соответствовала бы требованиям!

КЛ>>Компьютер работает с двоичной системой счисления, а двоичная система счисления — это позиционная система с основанием 2.

WH>Те невозможно построить комп на римских чиселках?
А попробуйте придумать такую микросхему. Похоже, Вы в запале опять взваливаете на себя задание, которое Вам не по зубам.

КЛ>>Если у Вас всего 4 контрола, то Вам не нужен и компонентный подход.

WH>1)Откуда следует что у меня только 4 контрола?
Вы сами это написали.

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

WH>Жизнь он облегчает тем что формализует контракты и не дает зацеписаться за детали реализации.
У Вас контракты не формализованы. Взять, к примеру, тот же тултип...

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

WH>Я уже говорил что это задокументированно:
WH>1)В описании объектной системы.
WH>2)В описании контрола.
Документирование — это хорошо. Но четко прописанный интерфейс — лучше. Это уже все тут, по момему, сказали.

Ладно, тултип можно схавать, если он только один. Конечно, кривовато. Но — бог с ним. А представьте, что среди таких контролов у Вас не один такой тултип, а несколько, которые что-то добавляют или, например, удаляют? Как во всем этом нагромождении разбираться? По каждому контролу смотреть документацию? Ну, можно. А есть ли документация по суперпозиции этих контролов? Ась? Ведь их — много. И каждый из них может что-то добавлять и что-то удалять. Контрактом это не ограничено.

WH>Но чукча похоже не читатель...

Вы опять грубите.

КЛ>>Можно ли будет в этом случае унифицировать вызывающий код и использовать его для обоих (attached и не-attached) случаев?

WH>Нельзя.
Аргументов, как я понимаю, ждать бесполезно?

КЛ>>Если нельзя, то почему?

WH>Я уже много раз писал.
Все, что Вы писали, я описал в диалоге. Конкретных деталей Вы так и не привели.
С уважением,
Кирилл Лебедев
Software Design blog — http://askofen.blogspot.ru/
Re[53]: О сопровождении
От: WolfHound  
Дата: 28.06.07 21:38
Оценка:
Здравствуйте, Кирилл Лебедев, Вы писали:

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

Его бы небыло в любом случае. Ибо мне а) не интересно. б) не платят.
Или ты хочешь оплатить мою работу?

КЛ>Итак, что же мы имеем на выходе? Вы построили суперабстрактную, но не работающую модель. Почему не работающую? Потому что нет ни одной реализации, которая соответствовала бы требованиям!

Оплати работу. Будет.
Это не проблема.

WH>>1)Откуда следует что у меня только 4 контрола?

КЛ>Вы сами это написали.
Где там было написано что есть только эти контролы?
Может не будешь выдумывать всякий бред?

КЛ>У Вас контракты не формализованы. Взять, к примеру, тот же тултип...

Как не формализованы?
Очень даже формализованы.

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

КЛ>Документирование — это хорошо. Но четко прописанный интерфейс — лучше. Это уже все тут, по момему, сказали.

А откуда следует что он не четко прописан?
Опять придумываешь?

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

Что кривовато?
Вот хардкодить тултипы во все контролы действительно кривовато.
Ибо потом захочеться добавить контекстные меню, биндинги, валидацию,... Все это тоже хардкодить во все контрлы? Кто-то тут выступал за то чтобы не дублировать функциональность. Ы?

КЛ>А представьте, что среди таких контролов у Вас не один такой тултип, а несколько, которые что-то добавляют

Я не только представил но и создал такую систему.
И все прекрасно работает.

Я больше скажу. Есть и другие системы работающие на подобных принципах.
И тоже не испытывают проблем с предсказуемостью.

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

КЛ>или, например, удаляют?

Это ты откуда взял?
Никто ничего не удаляет.
Хватит придумывать всякую ерунду.

КЛ>Как во всем этом нагромождении разбираться? По каждому контролу смотреть документацию? Ну, можно.

На практике любой у кого есть способность к абстрактному мышлению понимает все после прочтения описания модели объектной системы.
После этого для того чтобы понять как работает тот или иной контрол достаточно взглянуть на контракт этого контрола.

КЛ>А есть ли документация по суперпозиции этих контролов? Ась? Ведь их — много. И каждый из них может что-то добавлять и что-то удалять.

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

КЛ>Контрактом это не ограничено.

Опять придумываешь. Или просто переносишь на меня свой опыт проектирования?
Ведь это у тебя контракт не то что не ограничивает реализацию. У тебя вобще нет формальных контрактов.
Ибо если бы они были то у едита бы не появилась картинка, а у картинки не появился бы текст. Просто формальный контракт не позволил бы этому случиться. Но так как ты не озаботился контрактом мы имеем то что имеем.
Кстати я так и не получил ответ на вопрос: Зачем едиту картика?
Да вобщем и не мог... ибо ты сам не понял зачем ты это сделал.

WH>>Но чукча похоже не читатель...

КЛ>Вы опять грубите.
Я факты констатирую.

КЛ>Аргументов, как я понимаю, ждать бесполезно?

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

WH>Его бы небыло в любом случае. Ибо мне а) не интересно. б) не платят.

WH>Или ты хочешь оплатить мою работу?
Если Вы выдвигаете тезис, то бремя доказательства лежит на Вас. Это не моя проблема. Если не можете доказать, то честнее и порядочнее признать свою неправоту, а не придумывать отмазок в стиле:

а) "Я же — программист, напишу пару классов — и готово!"
б) "У меня есть умный интерфейс и абстрактная модель, а реализация может быть любой"
в) "Не хочу и не буду!"
г) "Мне за это денег не платят"

За свои слова надо отвечать. Если можете отвечать, то так честно и признаете свою ошибку. Если не можете — придумаете еще какую-нибудь отмазку.

WH>Где там было написано что есть только эти контролы?

WH>Может не будешь выдумывать всякий бред?
В Вашем сообщении.

КЛ>>У Вас контракты не формализованы. Взять, к примеру, тот же тултип...

WH>Как не формализованы?
WH>Очень даже формализованы.
Не формализованы — раз контрол, кинутый на форму, может добавлять тултипы ко всем другим контролам. Формализация бы была, если бы каждый из контролов, к которому добавляется тултип, имел бы метод Добавить тултип. Но и в этом случае решение было бы кривоватым.

WH>А откуда следует что он не четко прописан?

WH>Опять придумываешь?
В чем четкость? У Вас контролы, к которым добавляется тултип, имеют метод Добавить тултип?

WH>Что кривовато?

WH>Вот хардкодить тултипы во все контролы действительно кривовато.
WH>Ибо потом захочеться добавить контекстные меню, биндинги, валидацию,... Все это тоже хардкодить во все контрлы? Кто-то тут выступал за то чтобы не дублировать функциональность. Ы?
В Вашей компонентной модели ровно то и придется делать: либо хардкодить тултипы в контролы, либо добавлять их кривым способом, кидая на форму специальный контрол. И то, и другое — криво.

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

КЛ>>А представьте, что среди таких контролов у Вас не один такой тултип, а несколько, которые что-то добавляют

WH>Я не только представил но и создал такую систему.
WH>И все прекрасно работает.
Кошмар!

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

В моей модели нет едита, нет листбокса, нет комбобокса или какого-либо другого контрола, а есть:

а) данные для Z-ordering'а,
б) данные для layout'а,
в) данные для визуализации,
г) данные для подсказок,
д) данные для обработки сообщений,
е) и т.д.

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

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

КЛ>>или, например, удаляют?

WH>Это ты откуда взял?
WH>Никто ничего не удаляет.
WH>Хватит придумывать всякую ерунду.
Я просто развиваю Вашу модель в соответствии с Вашей же логикой: раз может существовать контрол, который что-то добавляет другим контролам на форме, следовательно, может существовать контрол, который что-то у них отнимает.

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

WH>А контракт каждого контрола содержит то и только то что должен делать этот контрол.
WH>Не больше и не меньше.
Ок. Пожалуйста, приведите тут контракт контрола, который добавляет тултипы.

WH>Опять придумываешь. Или просто переносишь на меня свой опыт проектирования?

WH>Ведь это у тебя контракт не то что не ограничивает реализацию. У тебя вобще нет формальных контрактов.
WH>Ибо если бы они были то у едита бы не появилась картинка, а у картинки не появился бы текст. Просто формальный контракт не позволил бы этому случиться. Но так как ты не озаботился контрактом мы имеем то что имеем.
WH>Кстати я так и не получил ответ на вопрос: Зачем едиту картика?
WH>Да вобщем и не мог... ибо ты сам не понял зачем ты это сделал.
Я уже ответил на этот вопрос несколько раз, например, здесь
Автор: Кирилл Лебедев
Дата: 03.06.07
. Если Вы не понимаете, повторю еще раз. Во-первых, это стандартный аналитический прием, который позволяет упростить работу с моделью (сократить код). Во-вторых, у меня нет контролов, как таковых (об этом я уже писал и детально разъяснял выше).

WH>>>Но чукча похоже не читатель...

КЛ>>Вы опять грубите.
WH>Я факты констатирую.
Это не факты, а Ваше личное мнение, выраженное в грубой форме.

КЛ>>Аргументов, как я понимаю, ждать бесполезно?

WH>Они были. Но ты не слушаешь.
Все что было — резюмировано в приведенном мною диалоге. Никакой конкретики — сплошной уход от вопросов.
С уважением,
Кирилл Лебедев
Software Design blog — http://askofen.blogspot.ru/
Re[58]: О сопровождении
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 29.06.07 08:42
Оценка:
Здравствуйте, Кирилл Лебедев, Вы писали:

AVK>>Там всего одна проверка и ее так просто сгруппировать не получится, потому что последовательность проверок в случае свойств и событий разная. В свойстве есть интерцептор и его надо обязательно проверять до проверки сериализуемости.

КЛ>А что такое интерцептор? В чем заключается его функция?

Читай внимательнее.

Интерцепторы нужны для работы со свойствами вроде Visible или Enabled в редакторе.

... << RSDN@Home 1.2.0 alpha rev. 688>>
AVK Blog
Re[58]: О сопровождении
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 29.06.07 08:42
Оценка:
Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>Потому что в противном случае запись выглядела бы так:


КЛ>Сериализовать Дерево

КЛ>1) ...
КЛ>2) ...
КЛ>3) Сериализовать Свойство

КЛ>Сериализовать Свойство

КЛ>1) ...
КЛ>2) ...
КЛ>3) ...

Ты сиквенс диаграммы вобще видел?
... << RSDN@Home 1.2.0 alpha rev. 688>>
AVK Blog
Re[59]: О сопровождении
От: Кирилл Лебедев Россия http://askofen.blogspot.com/
Дата: 29.06.07 09:03
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Читай внимательнее.

AVK>

Интерцепторы нужны для работы со свойствами вроде Visible или Enabled в редакторе.

А дифференциал Бульдожа нужен для повышения креативности...

Не могли бы Вы все-таки конкретизировать, что такое интерцептор и что он делает со свойствами Visible и Enabled.
С уважением,
Кирилл Лебедев
Software Design blog — http://askofen.blogspot.ru/
Re[60]: О сопровождении
От: Нахлобуч Великобритания https://hglabhq.com
Дата: 29.06.07 09:31
Оценка: 2 (1)
Здравствуйте, Кирилл Лебедев, Вы писали:


КЛ>Не могли бы Вы все-таки конкретизировать, что такое интерцептор и что он делает со свойствами Visible и Enabled.


Interceptor Pattern, описание тут, пример здесь (ПДФ).

Вообще — один из "строительных блоков" AOP
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
HgLab: Mercurial Server and Repository Management for Windows
Re[60]: О сопровождении
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 29.06.07 09:43
Оценка:
Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>Не могли бы Вы все-таки конкретизировать, что такое интерцептор и что он делает со свойствами Visible и Enabled.


Интерцептор перехватывает чтение и запись значений свойств при сериализации/десериализации. Зачем это нужно можно легко догадаться, если подумать о том, почему свойство Visible не может быть изменено у самого контрола в дизайн-тайме.
... << RSDN@Home 1.2.0 alpha rev. 688>>
AVK Blog
Re[55]: О сопровождении
От: WolfHound  
Дата: 29.06.07 10:08
Оценка:
Здравствуйте, Кирилл Лебедев, Вы писали:

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

Какой еще тезис? Это ты придумал кикието римские чисилки. И что-то пытаешься ими доказать.

WH>>Где там было написано что есть только эти контролы?

WH>>Может не будешь выдумывать всякий бред?
КЛ>В Вашем сообщении.
Цитату можно? Или ты сделал этот вывод на основании того что я других не перечислил?
Неужели человек работающий 11 лет в индустрии может всерьез считать что требования не меняются во времени? Или кто-то может просто о чемто забыть?

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

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

По этому я и убрал из контролов все то что не входит в их непосредственные обязанности. Те кнопка умеет нажиматься и только это она и умеет.

КЛ>В Вашей компонентной модели ровно то и придется делать: либо хардкодить тултипы в контролы, либо добавлять их кривым способом, кидая на форму специальный контрол. И то, и другое — криво.

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

КЛ>У меня же в модели существует специальная обобщенная операция — Работа с подсказками. И данные для нее хранятся отдельно. Никуда не хардкодятся и свободно удаляются, если не нужны.

Тултипы в моделе ГУИ?

КЛ>Кошмар!

Исключительно в твоем воображении.

КЛ>а) данные для Z-ordering'а,

А почему отдельно от лейаута?
КЛ>б) данные для layout'а,
Какого из?...
КЛ>в) данные для визуализации,
Какой из?...
КЛ>г) данные для подсказок,
В модели ГУИ?!
И эти люди запрещают мне ковыряться в носу...
КЛ>д) данные для обработки сообщений,
Они у всех контролов разные.
Те событие OnStartRowEdit имеет смысл у грида и только у грида. Кнопке оно не нужно.
КЛ>е) и т.д.

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

Те сидим и выпиливаем каждую кнопочку по отдельности?
Это по твоему упрощение разработки?

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

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

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

В твоей "системе" нет моделей. Там одна каша.

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

Никак одно из другого не следует.

КЛ>Ок. Пожалуйста, приведите тут контракт контрола, который добавляет тултипы.

    /// <summary>
    /// Провайдер подсказок
    /// </summary>
    [ReflectedExtendedObject]
    public interface IToolTipProvider
    {
        /// <summary>
        /// Установить текст подсказки для контрола
        /// </summary>
        [Reflected]
        void SetToolTip(object instance, string value);

        /// <summary>
        /// Получить текст подсказки контрола
        /// </summary>
        [Reflected]
        string GetToolTip(object instance);
    }

Легче стало?

КЛ>Я уже ответил на этот вопрос несколько раз, например, здесь
Автор: Кирилл Лебедев
Дата: 03.06.07
.

Куча наездов и передергиваний.
Их причина полное не понимание принципов создания полиморфных решений.

КЛ>Если Вы не понимаете, повторю еще раз.

КЛ>Во-первых, это стандартный аналитический прием, который позволяет упростить работу с моделью (сократить код).
Для кого?
Только не пытайся сюда приплести людей занимающихся созданием предметов материального мира.
Их опыт не применим. Вернее его применение оооочень ограничено.
У них полиморфизм не работает.
А в программировании работает.
А то что ты его не понимаешь... так это не проблемы полиморфизма.

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

Те полная деформализация системы.
Это было ясно с самого начала.
И именно по тому что у тебя все полностью деформализованно тебе и нужен конвеер.
А мне он не нужен по тому что мне нечего штамповать пачками. У меня все в одном экземпляре. Но этот экземпляр полиморфен.
Те там где ты штампуешь кнопки пачками я использую один раз написанную кнопку.

Пойми одну простую вещь: На описании вида

Создать форму и контролы.
Правильно структурировать дочерние контролы (т.е. прикрепить дочерние элементы к родительским).
Правильно расположить контролы на форме и внутри других контролов.
Отобразить форму и контролы.
Обрабатывать команды от контролов.
И т.д. (список далеко не полон).

Структурная модель.
Визуальная модель.
Топологическая модель.
Динамическая модель.

Формализация системы не заканчивается.
Она только начинается.

Те это ни разу не цель, а только начало процесса формализации системы.

КЛ>Все что было — резюмировано в приведенном мною диалоге. Никакой конкретики — сплошной уход от вопросов.

Ну что я могу поделать с тем что ты не понимаешь почему нельзя мух с катлетами мешать...
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[57]: О сопровождении
От: Кирилл Лебедев Россия http://askofen.blogspot.com/
Дата: 29.06.07 12:31
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Там всего одна проверка и ее так просто сгруппировать не получится, потому что последовательность проверок в случае свойств и событий разная. В свойстве есть интерцептор и его надо обязательно проверять до проверки сериализуемости.

Соответственно, можно подумать и об унификации последовательностей.

AVK>Да и смысла нет экономить на спичках — эта проверка просто вызов одного метода.

В этом есть смысл, т.к. унификация последовательности позволит:

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

Смотрите сами. В настоящий момент у Вас такие последовательности действий:

Для события:

1) Проверить событие на сериализуемость.
2) Получить значение события.
3) Записать значение в МСП.

Для свойства:

1) Получить интерцептор.
2) Проверить интерцептор на предмет желания перехватить свойство.
3) Получить значение свойства у интерцептора.
2а) Проверить свойство на сериализуемость.
3а) Получить значение свойства (у кого, если интерцептора нет — ?).
4) Сериализовать свойство в МСП.
4а) Свойство — компонент, владелец — несет ответственность за создание -> Сериализовать компонент.
4б) Свойство — компонент, владелец — не несет ответственности за создание -> Сериализовать ссылку на компонент.
4в) Свойство — коллекция, тогда — Сериализовать коллекцию.

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

Если абстрагироваться от деталей, то обе последовательности похожи. Поэтому их можно унифицировать и свести к такой последовательности:

1) Проверить элемент на сериализуемость.
2) Получить значение элемента для сериализации.
3) Записать значение в МСП.

Операция Проверить элемент на сериализуемость раскрывается так:

1) Элемент — событие: проверить на сериализуемость.
2) Элемент — свойство, и есть интерцептор: интерцептор проверить на сериализуемость.
3) Элемент — свойство, и нет интерцептора: свойство проверить на сериализуемость.

Операция Получить значение элемента для сериализации раскрывается так:

1) Событие: получить значение события.
2) Свойство и интерцептор: интерцептор получить значение свойства.
3) Свойство и нет интерцептора: свойство получить значение свойства.

Операция Записать значение в МСП раскрывается так:

1) Событие: записать значение события.
2) Свойство, компонент, владелец — несет ответственность, сериализовать компонент.
3) Свойство, компонент, владелец не несет ответственности, сериализовать ссылку на компонент.
4) Свойство, коллекция, Сериализовать коллекцию.

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

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

1) Проверить элемент на сериализуемость.
2) Получить значение элемента для сериализации.
3) Преобразовать полученное значение в значение для сериализации.
4) Записать значение в МСП.
С уважением,
Кирилл Лебедев
Software Design blog — http://askofen.blogspot.ru/
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.