Цитата:
Сообщение от
belugin
Проанализируй ключ в твоем примере - он составной - модуль и Node - можно их заменить именами классов?
можно.
только в этом случае связь с инфраструктурой аксапты тоже вручную писать нужно будет.
поэтому я использовал menuItem.
Цитата:
Сообщение от
belugin
У тебя есть класс с методом main, который все это знает. Я думал ты его имеешь ввиду. Я не создавал новых классов кроме атрибута. Есть класс-создаватель (фабрика) он готовый и я его не менял.
в проекте на конструкторах не было main, который ВСЕ ЗНАЕТ. было main, которые знали о себе (как обычно)
в проекте на конструкторах не было contruct, который ВСЕ ЗНАЕТ. было два конструктора. каждый знает только о своем уровне и принимает решение своего уровня.
в новом проекте на атрибутах действительно есть main, который должен знать обо всей иерархии. в проектике этого нет, потому что нет валидации входных данных. но в реальной жизни такая валидация обязательна.
Цитата:
Сообщение от
belugin
Тогда выбери любой другой пример.
не, давай пока останемся на том же самом - расширить функционал автосопоставления.
по идее, в этом примере не хватает параметров. ну и фиг с ними.
Цитата:
Сообщение от
belugin
Я уже отвечал. Если нужны параметры конструктора, то используется следующий прием:
Макс, ты снова рассказываешь "как это работает".
Я верю. Теперь я даже это видел своими глазами. "Прием" есть конечно.
Давай лучше поговорим о трудоемкости и об ответстенности за правильность результата.
Как бы ты оценил трудоемкость и удобность по сравнению со старым методом?
Мое мнение: Через жопу по сравнению со старым конструкторским методом.
Цитата:
Сообщение от
belugin
Тебе нужна иерархия классов или иерархия ключей?
...атрибуты никак не должны эту иерархию отражать
Вооот!!!
И мы подошли к трудоемкости и удобствам.
Раньше программист должен был знать только иерархию классов.
Теперь иерархия классов может (и должна) не совпадать с иерархией атрибутов.
Теперь программисту надо знать три вещи - иерархию классов, иерархию атрибутов и маппинг между ними. Во всех трех вещах могут быть ошибки. А поскольку в новом методе никакого контроля на этапе компиляции, то в новом методе ошибки будут неизбежно. Следовательно, потребуется большее время на изучение, написание, отладку и тестирования.
Цитата:
Сообщение от
belugin
Если первое, ... если второе, то ... правдя использована неколько раз там где надо делать классы ключами.
Именно!
Я посмотрел в существующий функционал насколько хватило терпения.
Пипец!!!
Цитата:
Сообщение от
belugin
Ok чуть попозже. Только учти что у тебя добавление элемента к существующему механизму создания объектов. А у меня будет еще и немного кода на перевод на новый механизм (как если бы ты перевел все на if вместо case
)
Если обратишь внимание, то во втором проекте у меня классы переведены на новый механизм. Во втором проекте нет конструкторов вообще.
Про добавление - я помню документацию и помню твои слова, где было только "добавление классов".
А вообще говоря, фреймворк должен успешно решать еще и задачи рефакторинга, изменения существующего функционала.
Я писал об этом выше.
Но фиг с ним. Давай пока останемся в рамках задачи "добавление класса в иерархию"
Цитата:
Сообщение от
belugin
Асинхронность это другой ортогональный аспект - нафига она тебе в создании экземпляра класса.
Да, ортогональный
Да, никакой асинхронности.
Да, я совершенно зря загорелся надеждой...
Цитата:
Сообщение от
belugin
Так же как и сейчас - кто и как распределяет префиксы в именах классов, чтобы партнерские классы не конфликтовали с микрософтовскими при обновлении.
"Также как и сейчас" - это ты очень хорошо сказал.
Если "также как и сейчас", то нафига огород городить?
А да, вспомнил, МС закрывает код базовых классов...
Цитата:
Сообщение от
belugin
- дает возможность разбить систему на независимые модули
- путем сведения общего пттерна "case" к частному "содание по ключу" позволяет автоматически сливать изменения в коде.
да-да. это понятно.
но я уже говорил, что это не единственный способ. и далеко не оптимальный.
Цитата:
Сообщение от
belugin
Зачем ты его просишь тогда?
и в самом деле!
Цитата:
Сообщение от
belugin
(Заметь что ты используешь разметку типа маркдауна внутри сообщения, но свою
)
Заметь, что в эту разметку никто не будет встраивать свои сообщения. На форуме при цитировании делается копия, старый текст и добавляется текст. И здесь нет компиляции )))
Цитата:
Сообщение от
belugin
Как раз паттерн позволяет вынести реализации каких-то веще в модели. Например в настройках можно добавить baseenum с форматомданных, а вам класс который реализует вывод в него вынести в расширение в другой модели.
Макс... Я понимаю что ты хочешь сказать. Но просто сделай проектик (чуть более сложный чем одноувроенвое семейство из трех классов) И покажи в нем что хочешь сказать.
Цитата:
Сообщение от
belugin
MS рефакторит. Несмотря на то, что при создании класса используется reflection это никак не мешает рефакторить
...майкрософту. пока билд не выпущен ))))
остальные не могут.
а тут еще и доступ к изменению исходного кода закроют.
Цитата:
Сообщение от
belugin
Чтобы создавать классы на основе бейзэнамов, например.
я понимаю, что ты хочешь сказать. но так делают только внутри МС.
Цитата:
Сообщение от
belugin
Именно поэтому твой case не по классам а по base enum и строчке - в menuItem нельзя записать три параметра все из которых были бы классами.
Вот ведь блин, выбрал я пример...
еще раз извиняюсь за дебильную реализацию семейства классов от МС -
наши люди в булошную на такси не ездют нормальные люди так не делают.
но фреймворк должен работать и с такими примерами тоже.
Цитата:
Сообщение от
belugin
Еще можно использовать сами классы в качестве ключей - посмотри SysClassNameAttribute
Да-да. У меня это был второй или третий вариант. В этом случае связь с классами автоматом, но зато связь с menuItem нужно делать руками.
Я старался сделать минимальный код при помощи штатных средств.