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

EC>Различия бывают как позитивные, так и негативные (в оригинале Positive and Negative Variability) и учитывать при проектировании надо и те и другие.
Полагаю, что это совершенно не важно. Потому что лучше концентрироваться не на различиях, а на сходстве. А вернее — на том, что нам нужно сделать с совершенно разными сущностями.

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

IB>Зачем метод Sort() делать членом класса коллекции? Очевидно его реализация будет пользоваться только публичным контрактом коллекции, так зачем этот метод делать членом класса коллекции, когда с тем же успехом

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

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

EC>>Различия бывают как позитивные, так и негативные (в оригинале Positive and Negative Variability) и учитывать при проектировании надо и те и другие.
КЛ>Полагаю, что это совершенно не важно.
На чём основано это положение?
КЛ>Потому что лучше концентрироваться не на различиях, а на сходстве. А вернее — на том, что нам нужно сделать с совершенно разными сущностями.
Предлагаю всё же ознакомиться с вышеозначенной книгой — она есть в p2p, можно хотя бы эту главу почитать.

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

КЛ>Такое впечатление, что Вы спорите сами с собой.
Такое впечатление, что ты не читаешь...

КЛ> Ну скажите, где я писал о том, что хочу сделать метод Sort() членом класса коллекции? Где? Укажите, плииз!
Если внимательно почитать, то станет очевидно, что это не моя идея, а Сергея Туленцова. И отвечал я ему, на его предположение о том, что ты имел ввиду (на основании чего он так предположил — другой вопрос и не ко мне).

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

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

WH>Проблема в том что конвеерное производство в программировании работает очень плохо.
У нас в компании программы, в основе которых лежит конвеерная архитектура, работают хорошо. А если бы они были бы сделаны по-другому, то оказались бы либо слишком сложными, либо постоянно глючили бы, либо и то и другое.

Само производство программ у нас пока не конвеерное. Но ряд шагов в этом направлении тоже сделан.

WH>Ибо если появляется что-то что можно производить конвеерным способом то есть 99.9999999% вероятность что это автоматизируется.
WH>А если что-то можно автоматизировать то это должно быть автоматизировано.
Разумеется. Об этом я и говорил. При конвеерной архитектуре один шаг "Создание контрола" разбивается на ряд более простых операций:

1) Создание функциональной модели.
2) Создание топологической модели.
3) Создание лэйаута.
4) Создание визуального представления.
5) И т.д.

WH>Ты просто не понимаешь принципов построения слабосвязанных компонентных архитектур.

Это не так. Если отбросить код на C# и немерле и описать суть решения на концептуальном уровне, то Вы предложили:

1) Заменить listbox (список элементов в одну колонку) гридом (списком элементов в N колонок).
2) Абстрагироваться от содержимого ячейки грида (т.е. в ячейке может содержаться либо кнопка, либо эдит, либо статический текст, либо картинка, либо что-нибудь еще, например, другой контрол).

Продолжение следует...

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

КЛ>У нас в компании программы, в основе которых лежит конвеерная архитектура, работают хорошо. А если бы они были бы сделаны по-другому, то оказались бы либо слишком сложными, либо постоянно глючили бы, либо и то и другое.
Проблема в том что закон сохранения сложности никто не отменял.
Сложность нельзя убрать.
Ее можно только перераспределить.

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

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

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

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

    grid.DataSource = select * from goods where count > MinCount;

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

А главное что эта логика написана и отлажена 1 раз. И ее не видно в прикладном коде.

Да над библиотекой придется поколдовать. Но сделать это нужно один раз.

КЛ>Само производство программ у нас пока не конвеерное. Но ряд шагов в этом направлении тоже сделан.
Хочешь конкурировать с индусами на их поле?
По цене не потянешь.
Единственный способ их победить это использовать мощьные технологии.

WH>>Ибо если появляется что-то что можно производить конвеерным способом то есть 99.9999999% вероятность что это автоматизируется.
WH>>А если что-то можно автоматизировать то это должно быть автоматизировано.
КЛ>Разумеется. Об этом я и говорил. При конвеерной архитектуре один шаг "Создание контрола" разбивается на ряд более простых операций:
Это все лирика.
Это делается по умолчанию и на автопилоте.

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

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

КЛ>Если отбросить код на C# и немерле и описать суть решения на концептуальном уровне, то Вы предложили:
Так код это главное.
Ведь цель получить код который делает то что нужно.
При этом его должно быть мало, он должен быть простым, делать то что нужно качественно и быстро и его должно быть просто развивать.
А единственный известный мне способ добиться этого это сделать все максимально декларативным.

КЛ>1) Заменить listbox (список элементов в одну колонку) гридом (списком элементов в N колонок).
VirtualTreeGrid'ом если быть точным.
Virtual означает то что он не требует чтобы были подняты все данные. Ибо данных может быть очень много.
Tree означает что я могу отображать не только плоские но и иерархические структуры. А также проводить группироваку плоских. Причем благодоря умной прокладке между базой и гридом группировкой будет заниматься база. Причем для этого не понадобится никаких движений со стороны прикладного программиста.

КЛ>2) Абстрагироваться от содержимого ячейки грида (т.е. в ячейке может содержаться либо кнопка, либо эдит, либо статический текст, либо картинка, либо что-нибудь еще, например, другой контрол).
Опять не точно.
Никаких либо. Никакой конкретики.
В ячейке может быть абсолютно любой контрол.

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

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

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

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

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

КЛ>Я же в данном случае стараюсь применить иной подход — пытаюсь сконцентрироваться не на том, что свойство и событие различает, а на том, что их объединяет. Почему? Потому что в случае успешности попытки, можно будет уменьшить количество сущностей (интерфейсов) и, как результат, сократить вызывающий код. Т.е. вместо двух участков кода, один из которых работает с IPropertyBase, а другой — с IEventBase, можно будет получить один участок кода без какого-либо усложнения.
Такие случаи видны сразу. Причем сразу же находится то что эти сущьности роднит.
Например IAttachedElement.
Выделение этого интерфейса в некоторых случаях позволило обобщенно работать с IAttachedEvent и IAttachedProperty.
Но в отличии от предлогаемых тобой притянутых за уши обобщений это абсолютно логическое обобщение.
И то и другое может цепляться к объекту.
Следовательно можно выделить сущьность которая цепляется к объекту.

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

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

КЛ>Во втором варианте — существует единая таблица, которая связывает прикрепленное свойство и объект.
Зачем единая?
Зачем себя ограничивать?

КЛ>Опять-таки, этот вариант — лишь повод для размышления, т.к. возможно он поможет снять проблему дублирования.
Нет никакого дублирования. Его ты придумал.

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

КЛ>>2) Абстрагироваться от содержимого ячейки грида (т.е. в ячейке может содержаться либо кнопка, либо эдит, либо статический текст, либо картинка, либо что-нибудь еще, например, другой контрол).
WH>Опять не точно.
WH>Никаких либо. Никакой конкретики.
WH>В ячейке может быть абсолютно любой контрол.

Да ты просто пишешь высоко-полиморфный код, который "мономорфизироваться" будет где-нибудь в Индии. А твой оппонент пытается его "преждевременно мономорфизировать" Понятно, что многие "священные принципы" прикладного ООП у тебя не работают. Поскольку объект, будучи создан, всегда имеет конкретный мономорфный тип, а ты с конкретными объектами уже дела не имеешь. Это всё ФП-зараза

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

ГВ>>Это алгоритм чего конкретно?
WH>Заполнения PropertyGrid'а в дизайнере для выбранного контрола.

"Родитель", "дед" и пр. — это связь между классами или между экземплярами? Иными словами, это наследование или ссылки вроде owner/parent?

[...]

WH>Например когда рисуешь диалог удобно без написания кода выставить кнопке предопределенные действия например Ok/Cancel. А если впсомнить про web то это становится просто необходимым.
WH>Таким образом у диалога заводится присоедененное свойство которое цепляется только к кнопкам.

У диалога заводится такое свойство? То есть оно как-то привязывается к экземпляру контейнера?

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

ГВ>>Возможно. Хотя, ИМХО, экземпляры можно создавать непосредственно перед использованием.

AVK>Можно. Но алгоритмы диайнера и сериализатора таковы, что это создаст очень серьезный оверхед. Количество контролов, помноженное на количество свойств, помноженное на количество attached свойств, помноженное на количество проходов даст очень неслабую цифру.

Значит, надо смотреть и на эти алгоритмы. Я пока не понимаю, как минимум, почему эти числа надо именно перемножать. Да и генерация свойств для PropertyGrid-а по словам Wolfhound-а

Автор: WolfHound
Дата: 22.06.07

:

Так что проще сгенерить блпго это практически ничего не стоит.

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

AVK>Не всегда.

Не может быть. Здесь же не унифицированы интерфейсы Native и Attached. Ergo, пользователь всегда знает, с чем работает. Под "пользователем" я имею ввиду программиста, разумеется.

ГВ>>С другой стороны, stateless-дизайн можно ещё оправдать тем, что ситуация с выполнением многочисленных одинаковых операций для свойств разных объектов (например, SetValue для всех контролов) встречается чаще, чем вызов разных методов для одного объекта (например, последовательность CanReset/Reset/GetValue или что-то в этом роде). Но я бы тут подумал, что в конечном итоге лучше — быстро создавать объект или передавать один-два дополнительных параметра.

AVK>Вариантов решения проблемы хватает. Сейчас, к примеру, owner передается в любом случае, просто для обычного свойства он игнорируется.

А куда передаётся owner?

AVK>Можно еще визитор использовать. Если в языке есть pattern matching, то можно использовать его. Вобще, в реальном проекте все намного сложнее и хитрее, но смысла это все описывать здесь нет.

ИМХО — есть. Уж коль скоро появились конкретные интерфейсы.

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

ГВ>"Родитель", "дед" и пр. — это связь между классами или между экземплярами?
Между объектами.

ГВ>Иными словами, это наследование или ссылки вроде owner/parent?
Второе.

ГВ>У диалога заводится такое свойство? То есть оно как-то привязывается к экземпляру контейнера?
Attached элементы это такие волшебные элементы которые принадлежат одним объектам, а цепляются к другим.

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

ГВ>Значит, надо смотреть и на эти алгоритмы. Я пока не понимаю, как минимум, почему эти числа надо именно перемножать. Да и генерация свойств для PropertyGrid-а по словам Wolfhound-а

Автор: WolfHound
Дата: 22.06.07

:

ГВ>

ГВ>Так что проще сгенерить блпго это практически ничего не стоит.

В дизайнере форм. По запросу пользователя. А генерить все в рантайме на на каждую сериализацию/десериализацию уже дорого.

ГВ>Не может быть. Здесь же не унифицированы интерфейсы Native и Attached. Ergo, пользователь всегда знает, с чем работает. Под "пользователем" я имею ввиду программиста, разумеется.
Тут смотря какой программист.
Разработчик системных компонентов да.
А те кто пишут бизнес логику как правило нет.
Бросил кнопку на форму. Выставил те свойства что появились в PropertyGrid'е и пошол дальше.

ГВ>ИМХО — есть. Уж коль скоро появились конкретные интерфейсы.
Это ты скатываешься к предложению схожему с преложением Кирилла описать все детали скрещивания win с web. Никто этого делать не будет.

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

ГВ>Значит, надо смотреть и на эти алгоритмы. Я пока не понимаю, как минимум, почему эти числа надо именно перемножать.

Это долго расписывать.

ГВ> Да и генерация свойств для PropertyGrid-а по словам Wolfhound-а

Автор: WolfHound
Дата: 22.06.07

:

ГВ>

ГВ>Так что проще сгенерить блпго это практически ничего не стоит.

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

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

AVK>>Не всегда.

ГВ>Не может быть. Здесь же не унифицированы интерфейсы Native и Attached.

Еще раз повторю — все намного сложнее в реальности, чем здесь описывается.

AVK>>Вариантов решения проблемы хватает. Сейчас, к примеру, owner передается в любом случае, просто для обычного свойства он игнорируется.

ГВ>А куда передаётся owner?

В специальный объект, аналог PropertyDescriptor.

ГВ>ИМХО — есть. Уж коль скоро появились конкретные интерфейсы.

Это не конкретные интерфейсы, конкретные интерфейсы отличаются от того, что приводил WH.

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

WH>Проблема в том что закон сохранения сложности никто не отменял.
Такого закона не существует.

WH>Сложность нельзя убрать.
WH>Ее можно только перераспределить.
Пример, который я уже приводил не раз: перемножьте XLVII и XCIV, не преобразуя их в позиционную систему счисления с фиксированным основанием.

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

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

Конвеер — хорошо решает проблему сложности. Это было уже доказано не раз.

WH>Это все лирика.
WH>Это делается по умолчанию и на автопилоте.
У Вас контролы как пишутся? Каждый контрол пишет один программист от начала и до конца? Или есть специализация "написальщиков" контролов? Один программист — составляет функциональные требования ко всем контролам (и только этим и занят), другой — продумывает дизайн (и только этим и занят), третий — занимается layout'ами (и только этим и занят), четвертый — занимается топологией (и только этим и занят), пятый — занимается алгоритмами визуализации (и только этим и занят)?

Т.е. у Вас существует специализация работников на продемонстрированном уровне или у Вас есть только "написальщики контролов"? Существует ли у Вас разделение операций в пространстве и/или во времени?

Если этого нет, то ни о каком "автопилоте" и речи быть не может.

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

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

КЛ>>Если отбросить код на C# и немерле и описать суть решения на концептуальном уровне, то Вы предложили:
WH>Так код это главное.
Странно слышать такие утверждения после длинных разговоров про инкапсуляцию, компонентный подход и абстрагирование.

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

КЛ>>1) Заменить listbox (список элементов в одну колонку) гридом (списком элементов в N колонок).
WH>VirtualTreeGrid'ом если быть точным.
Предлагаю заменить этот термин на "контрол, который проявляет свойства дерева и грида".

WH>Virtual означает то что он не требует чтобы были подняты все данные. Ибо данных может быть очень много.
"...способный подгружать данные определенными порциями по мере необходимости".

КЛ>>2) Абстрагироваться от содержимого ячейки грида (т.е. в ячейке может содержаться либо кнопка, либо эдит, либо статический текст, либо картинка, либо что-нибудь еще, например, другой контрол).
WH>Опять не точно.
WH>Никаких либо. Никакой конкретики.
Здесь через "либо" перечислены конкретные примеры. Само собой разумеется, что при проектировании грида не нужно завязываться на какой-либо конкретный перечень контролов.

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

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

КЛ>>Тем не менее и тот и другой интерфейс Вы вывели из IElementBase, т.е. хотели показать, что и свойство, и событие являются элементами. Это означает, что между свойством и событием есть нечто общее.
WH>И туда вынесено ровно то что должно быть вынесено.
Да, но это дробление сущностей, а не обобщение. Вынести можно и так, и эдак. Но в моем варианте количество сущностей сокращается.

КЛ>>Почему же тогда не продемонстрировать эту общность и не назвать свойство ElementType?
WH>По тому что не нужно объеденять мух с котлетами.
Это — не аргумент.

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

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

Например, у меня такой критерий есть: обобщение, которое сокращает вызывающий код, является "абсолютно логичным". А вот если обобщение плодит сущности, то оно — "притянуто за уши".

Если Вы с этим критерием согласны, то давайте и оценивать решения, исходя из него. Если не согласны, то предложите свой критерий.

WH>И то и другое может цепляться к объекту.
WH>Следовательно можно выделить сущьность которая цепляется к объекту.
Древнекитайская классификация животных делила их на четвероногих, крылатых, нарисованных тушью, принадлежащих императору и т.п.Вам не приходит в голову, что предложенная Вами классификация элементов объекта на свойства, события, добавленные свойства, добавленные события напоминает китайскую классификацию?

КЛ>>Если все различие заключается в количестве передаваемых параметров, то код можно сократить, т.е. от одного интерфейса можно просто избавиться.
WH>Нельзя. Ибо от логики получения второго объекта всеравно не избавиться.
"Логику получения второго объекта" можно инкапсулировать.

КЛ>>Во втором варианте — существует единая таблица, которая связывает прикрепленное свойство и объект.
WH>Зачем единая?
WH>Зачем себя ограничивать?
В этом случае мы имеем один объект, которому делегируем обязанность получать и устанавливать значения добавленных свойств и событий. Получается: 1 обязанность — 1 класс — 1 объект. Легко менять и разбираться в случае чего.

КЛ>>Опять-таки, этот вариант — лишь повод для размышления, т.к. возможно он поможет снять проблему дублирования.
WH>Нет никакого дублирования. Его ты придумал.
Вы же сами утверждали — код, работающий с IProperty и IAttachedProperty похож.

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

WH>>Проблема в том что закон сохранения сложности никто не отменял.
КЛ>Такого закона не существует.
Это тебе так кажется.

КЛ>Пример, который я уже приводил не раз: перемножьте XLVII и XCIV, не преобразуя их в позиционную систему счисления с фиксированным основанием.
Ну не надо так подстваляться.
Мы же на форуме программистов, а не тех кто на компе может только тексты в ворде набивать.
На любом приличном языке это будет выглядить так (с точностью до синтаксиса):

RomanNumber n1("XLVII");
RomanNumber n2("XCIV");
RomanNumber n3 = n1 * n2;

Остальное детали реализации не имеющие никакого значения на данном уровне абстракции.

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

Недавно мне нужно было посчитать статистику по логам. Я использовал модель потоков и филтров. Сведя задачу к декларативной.
Болие того данная модель прекрасно распаралеливается что в свете смещеня акцента с гигагерцов на многоядерность становиьтся актуально.
Но это всеголишь побочный эффект. Главное тут то что код получился декларативным.

А как ты думаешь почему римская система появилась раньше позиционной?
Да все просто.
У нее абстракция нулевая.
Каждая цифра обозначает конкретное число.
Не больше и не меньше.
Модель проста как палка.
А в случае с позиционной нужно понимать что цифры не сами по себе, а зависят от позиции.
Те сложность умножения ни куда не делась.
Мы просто спрятали ее при помощи абстракции.
А если посмотреть на тот код что я привел выше то абстракция поднята еще выше.
Там просто введено обозначение умножения чисел и все.
Ни какого конкретного алгоритма там нет.
Он спрятан внутри класса RomanNumber.
А как уж он реализован это другой вопрос.
Переводим ли мы в позиционныю систему исчисления или перемножаем напримую римские чиселки совершенно не важно.
Болие того мы можем заменить одно на другое так что прикладной код использующий умножение этого не заметит.
Те допустим мы изначально не знали о позиционной системе исчисления и реализовали умножение в лоб.
Но потом открыли позиционную систему и мы спокойно перевели внутренности класса RomanNumber на болие продвинутые алгоритмы разогнав его работу.
При этом тонны кода которые использовали умножение (и прочие операции) не изменились, а просто стали работать быстрее.
Все это благодоря тому что была использована абстракция болие высокого уровня чем непосредственно конкретный алгоритм умножения.

КЛ>Конвеер — хорошо решает проблему сложности. Это было уже доказано не раз.
Конвеер хорошо решает только массовое штампование совершенно одинаковых чайников по один раз нарисованному чертежу.
Однако в случае с программой нет никакого массового штампования. (Вернее оно есть но оно давно и полность автоматизировано. Компилятор + утилита copy == сколько угодно копий какой угодно программы. Чайникам такое и не снилось.)

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

Причем в случае с техникой действуют теже законы. Просто не в таких масштабах как в случае с программами.

Нарпмер есть модели: колесо, винт + гайка, блок,...

Создание таких моделей автоматизировать невозможно.

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

КЛ>Т.е. у Вас существует специализация работников на продемонстрированном уровне или у Вас есть только "написальщики контролов"? Существует ли у Вас разделение операций в пространстве и/или во времени?
Те по твоему каждую кнопку должны делать такое колличество народу?
Зачем нужен человек который выдумавает внейшний вид я еще могу понять.
Зачем нужен человек который глушит водку с клиентом я тоже понимаю.
А вот задействовать на разроботке кнопки больше одного человека просто не имеет смысла ибо объем работ там практически никакой. Они дольше объяснять друго другу будут что нужно сделать.
Да обсудить и утвердить общею концепцию системы нужно. Но проектировать толпой народа кнопку... это мягко говоря перебор.

КЛ>Если этого нет, то ни о каком "автопилоте" и речи быть не может.
А по чему этот автопилот не может работать на уровне одного человека?

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

2)Клиенты они разные бывают. Некоторые очень фенечки любят.

3)Если клиент за небольшую дополнительную плату получит еще и фенечку которая ему нравится то он будет счеслив.

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

WH>>Так код это главное.
КЛ>Странно слышать такие утверждения после длинных разговоров про инкапсуляцию, компонентный подход и абстрагирование.
Нет ничего странного.
Одно другому помогает.
Я умею использовать абстракции для того чтобы упрощать разработку и поддержку кода.
Болие того это дает мне возможность решать такие задачи которые те кто не обладают такими способностями не решат ни когда. Даже очень большой толпой.

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

WH>>VirtualTreeGrid'ом если быть точным.
КЛ>Предлагаю заменить этот термин на "контрол, который проявляет свойства дерева и грида".
Хоть горшком назови.

WH>>Virtual означает то что он не требует чтобы были подняты все данные. Ибо данных может быть очень много.
КЛ>"...способный подгружать данные определенными порциями по мере необходимости".
Нет. Данные могут быть в массиве, в базе, генериться на лету,...
Контролу такие мелочи знать не нужно.
Контролу подсовывают объект реализующий интерфейс и он у него и запрашивает данные.
Все. Ничего другого контрол не знает.
Ни про базу, ни про массивы, ни про войну римлян с варварами...

КЛ>Здесь через "либо" перечислены конкретные примеры. Само собой разумеется, что при проектировании грида не нужно завязываться на какой-либо конкретный перечень контролов.
Просто само по себе появление "либо" весьма подозрительно.
Лично мне конкретные контролы даже в голову не приходили когда я это продумывал.
Ибо они не имеют значения.

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

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

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

КЛ>Почему?
По тому что нет мест которым хватает IElementBase и нужен тип элемента.
И быть не может ибо типы разные.

КЛ>Пока у Вас нет критериев "абсолютно логического обобщения", невозможно сказать, какое обобщение "логическое", а какое — "притянуто за уши".
Почему же? Если в нектором контексте связь отвечает на вопрос "is a" то можно обобщать.
Если нет то нельзя ибо даже если мы вдруг сможем гдето немного срезать то нам это аукнется при поддержке.

КЛ>Например, у меня такой критерий есть: обобщение, которое сокращает вызывающий код, является "абсолютно логичным". А вот если обобщение плодит сущности, то оно — "притянуто за уши".
Те сокращение колличества кода и сущьностей любой ценой?
Странный критерий.
В лучшем случае получишь небольшое преимущество на очень коротких дистанциях.
Но на длинной дистанции закопаешься.

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

Если в модель ни добавить ни убавить без потери целостности то это хорошая модель.
Модель интерфейсов сейчас выглядит так:

Модель симметрична. Отсутствие любого элемента приведет к потери симметрии. Добавление тоже.

Вобще картинке место в начеле теста IQ.
Можно убрать 3 интерфейса находящихся в разных строках и разных столбцах и по остальным можно однозначно востановить пропущенные.
Даже не зная значения тех слов что там написаны.

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

Причем даже если бы там были интерфейсы бездельники я бы всеравно картинку ломать не стал ибо:
1)В данном случае интерфейсы ничего не стоят.
2)Практика показывает что если появляется подобная картинка то рано или поздно таки придется закрыть все дыры. И лучше это сделать рано чтобы не пришлось код трогать.

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

WH>>Нельзя. Ибо от логики получения второго объекта всеравно не избавиться.
КЛ>"Логику получения второго объекта" можно инкапсулировать.
Так она и нкапсулирована на том уровне где работают с метаданными...
На другие уровни ни эта логика ни эти интерфейсы не вылезают.

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

КЛ>Вы же сами утверждали — код, работающий с IProperty и IAttachedProperty похож.
Гдето похож. Гдето нет. Гдето похожи механизмы работы IAttachedProperty и IAttachedEvent...
Короче всем интерфейсам работа есть...

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

ГВ>>Не может быть. Здесь же не унифицированы интерфейсы Native и Attached. Ergo, пользователь всегда знает, с чем работает. Под "пользователем" я имею ввиду программиста, разумеется.
WH>Тут смотря какой программист.
WH>Разработчик системных компонентов да.
WH>А те кто пишут бизнес логику как правило нет.
WH>Бросил кнопку на форму. Выставил те свойства что появились в PropertyGrid'е и пошол дальше.

ГВ>>ИМХО — есть. Уж коль скоро появились конкретные интерфейсы.
WH>Это ты скатываешься к предложению схожему с преложением Кирилла описать все детали скрещивания win с web. Никто этого делать не будет.

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

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

ГВ>>Значит, надо смотреть и на эти алгоритмы. Я пока не понимаю, как минимум, почему эти числа надо именно перемножать.
AVK>Это долго расписывать.

А ты попробуй.

ГВ>> Да и генерация свойств для PropertyGrid-а по словам Wolfhound-а

Автор: WolfHound
Дата: 22.06.07

:
ГВ>>

ГВ>>Так что проще сгенерить блпго это практически ничего не стоит.

AVK>Генерация свойств для PG не есть проблема, потому что как раз там при смене выделения надо создать максимум сотню объектов, что не приведет к хоть сколько нибудь заметным проблемам. А вот к метаданным обращений и при сериализации и в дизайнере сильно больше, да и ограничения по производительности в случае сериализации значительно жестче.

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

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

AVK>>>Не всегда.
ГВ>>Не может быть. Здесь же не унифицированы интерфейсы Native и Attached.
AVK>Еще раз повторю — все намного сложнее в реальности, чем здесь описывается.

Дык в том-то и прикол, что для того, чтобы опровергнуть, например, посылки Кирилла нужно расписать всю постановку задачи от и до. В противном случае получается разговор ни о чём, где одни всё время утыкаются в неполноту информации, а другие утверждают, что её долго и муторно расписывать. Странно это как-то.

AVK>>>Вариантов решения проблемы хватает. Сейчас, к примеру, owner передается в любом случае, просто для обычного свойства он игнорируется.
ГВ>>А куда передаётся owner?
AVK>В специальный объект, аналог PropertyDescriptor.

А назначение этого объекта?

ГВ>>ИМХО — есть. Уж коль скоро появились конкретные интерфейсы.
AVK>Это не конкретные интерфейсы, конкретные интерфейсы отличаются от того, что приводил WH.

То есть, фактически, это такой сфероконь? А мы-то здесь копья ломаем... Великолепно, брависсимо!

2 WolfHound: Это так и есть, что ли?

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

ГВ>>>Значит, надо смотреть и на эти алгоритмы. Я пока не понимаю, как минимум, почему эти числа надо именно перемножать.
AVK>>Это долго расписывать.
ГВ>А ты попробуй.
Если в двух словах то в твоей модели на каждый десериализуемый объект нужно создавать еще пару десятков объектов.
Причем цель жизни каждого из них один раз установить значение свойства.
Это дорого.
Да и не нужно ибо создание + однократное использование твоего объекта не проще чем однократное использование моего.

ГВ>Ясно. Я пока склоняюсь к тому, что те интерфейсы, который показал WolfHound — это очень низкий уровень в иерархии абстракций. Ergo, надо копать остальные абстракции тоже.
Не надо. Это абсолютно самодостаточная модель.

ГВ>Дык в том-то и прикол, что для того, чтобы опровергнуть, например, посылки Кирилла нужно расписать всю постановку задачи от и до.
Не нужно. В прочем ты себя послушай... расписать задачу от и до. Да где ты такое видел? Такого не бывает ни где и ни когда. В принципе.
Ну разве что сюда опять зайдут программисты софта для АЭС или шатлов

Что касается посылок достаточно посмотреть к чему они приводят... А приводят они к ужасной лапше в которой все завязано на все.
Просто идеи типа дать всем контролам текст и картинку с моей точки зрения является абсолютно не допустимыми при создании чего бы то нибыло.
И не надо тут говорить про пример, затычку, отмазку и тп. Данное решение говорит лучше 1000 слов. Я никогда не позволю себе такое даже в качестве отмашки. Я корее просто пошлю чем изрбражу такое.

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

А тому что напректировал Кирилл ничето не поможет.
Ибо он действует из совершенно не верных посылок.
И наиболие фатальныя из них это: Система должна быть минимальной.
БРЕД! Эта посылка работает при создании материальных систем ибо там основные затраты это воплощение в железе, камне и тп. Хотя даже тут пока еще работает... ибо чем дальше тем не матереальная составляющея становится все больше и больше.

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

Но тут и близко не тот случай.
Сравнивается макаронная архитектура в которой все завязано на все и при попытке добавить то на что в начале создания не закладовались все посыпится. Скажем сплайн лейаут Кирилл не добавит никогда ибо на него не расчитана система. Он просто не влезет в его таблички. Никак.
Разве что ему придется поравить все.

Со слабосвязанной компонентной системой которой в очень широких рамках всеравно с чем работать.
Этой системе всеравно кто и что захочет в нее добавить. Она сожрет любой контрол и любой лейаут.
И для этого не нужно ничего менять. Нужно только написать новый контрол.

Да в первой системе сущьностей и возможно кода на первых этапах меньше.

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

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

ГВ>В противном случае получается разговор ни о чём, где одни всё время утыкаются в неполноту информации, а другие утверждают, что её долго и муторно расписывать. Странно это как-то.
Ты что тоже не понимаешь чем win от web отличается и почему за 5 минут на коленке под них общий интерфейс не подвести?

ГВ>То есть, фактически, это такой сфероконь? А мы-то здесь копья ломаем... Великолепно, брависсимо!
Это мои интерфейсы.
Они очень похожы на то что я сделал работая вместе с Андреем.

ГВ>2 WolfHound: Это так и есть, что ли?
Сейчас я там не работаю и не знаю что именно там происходит.
Но когда уходил оставлял все практически так как показал.
За исключением мелочей (типа имен интерфейсов), того что это было написано под первый фреймворк и одного большого класса с кучей статических функций часть которых уехала в реализацию IDomain, другие были заменены на public IEnumerable<T> FilteredElements<T>() where T : class, IElementBase, а третьи просто умерли из-за того что я сделал болие чистую модель. В частности заполнил дырку на той картинке и ввел интерфейс IType.
Те изменения косметические.
Суть не изменилась.

Для тех кто не понял в чем суть повторю еще раз:
1)Отделить от объектов (контролов в частности) то что им знать не нужно.
2)Обеспечить работу абстрактных сериалайзеров и дизайнеров с данной объектоной моделью.