|
![]() |
#1 |
Участник
|
Цитата:
Цитата:
Снова приношу свои извинения за безумную реализацию от МС.
Нет, у меня не нужен класс запускач. Достаточно menuItem, который подцепляется к главному меню или к формам. Цитата:
Нет )))
На реальных проектах простейший случай без стратегии - скорее исключение. На реальных проектах именно "стратегия" и зашита-размазана в конструкторах. Каждый конструктор отвечает за свою часть. Цитата:
В фреймворке один стратегия должна знать обо всех классах иерархии.
Цитата:
ты снова прав для случая без параметров.
но как часто используется именно этот сценарий? 1. Во базовый класс добавляется метод init с нжными параметрами 2. Сразу после создания он вызывается. Цитата:
выбери любой из них, который реализует несколько уровней иерархии.
Если первое, то атрибуты никак не должны эту иерархию отражать, если второе, то то есть отдельная обертка для иерархических атрибутов, которая, правдя использована неколько раз там где надо делать классы ключами. Цитата:
Покажи как это просто.
Ты говоришь "просто добавить атрибуты". Ты говоришь "просто смотреть" Сделай проектик. Покажи как это просто. ![]() Цитата:
И в самом деле! Чего это я? Видать Котлинов всяких наелся...
Цитата:
Я смотрю актуальную аксапту. 7.2.1785.0
Да-да. Я вижу это "что угодно". Строка с ; Это пипец и детский сад какой-то. Цитата:
Кем и как? Бгггг!!
Цитата:
вспомнить, исходный вопрос ветки был: "Какая цель создания экземпляров классов через расширенные атрибуты? Чем не устраивает старый дедовский способ construct?"
- путем сведения общего пттерна "case" к частному "содание по ключу" позволяет автоматически сливать изменения в коде. Цитата:
Ребяты, прошу вас, не надо примеров "я создал пример из трех классов, я добавил атрибуты". такие примеры ничего не показывают.
Цитата:
Давайте рассматривать нормальный промышленный случай:
= которые добавляют/изменяют функционал этого семейства (одновременно или последовательно). в пределе это программисты разных партнеров, которые делают разные типовые решения. а некий программист заказчика ставит эти пересекающиеся типовые решения [из разных моделей]. (в целях упрощения, для данной ветки можно предположить, что модель одна, чтобы рассмотреть только механизм инстанцирования класса) = как облегчить работу этих людей? ![]() Как раз паттерн позволяет вынести реализации каких-то веще в модели. Например в настройках можно добавить baseenum с форматомданных, а вам класс который реализует вывод в него вынести в расширение в другой модели. Цитата:
Как должны выглядеть эти ключи, чтобы разные люди могли добавлять классы-потомки и не мешать друг-другу?
Я предпочитаю привязываться к именам классов и таблиц. Цитата:
Как должны выглядеть эти ключи, чтобы в принципе была возможность рефакторинга? (да, я знаю что МС не рефакторит, но у партнеров и у заказчика то могут работать нормальные люди)
Цитата:
Зачем вообще нужны специальные ключи вместо имен классов?
Еще можно использовать сами классы в качестве ключей - посмотри SysClassNameAttribute |
|
|
За это сообщение автора поблагодарили: macklakov (10). |
![]() |
#2 |
Участник
|
Цитата:
только в этом случае связь с инфраструктурой аксапты тоже вручную писать нужно будет. поэтому я использовал menuItem. Цитата:
в проекте на конструкторах не было contruct, который ВСЕ ЗНАЕТ. было два конструктора. каждый знает только о своем уровне и принимает решение своего уровня. в новом проекте на атрибутах действительно есть main, который должен знать обо всей иерархии. в проектике этого нет, потому что нет валидации входных данных. но в реальной жизни такая валидация обязательна. не, давай пока останемся на том же самом - расширить функционал автосопоставления. по идее, в этом примере не хватает параметров. ну и фиг с ними. Цитата:
Я верю. Теперь я даже это видел своими глазами. "Прием" есть конечно. Давай лучше поговорим о трудоемкости и об ответстенности за правильность результата. Как бы ты оценил трудоемкость и удобность по сравнению со старым методом? Мое мнение: Через жопу по сравнению со старым конструкторским методом. Цитата:
И мы подошли к трудоемкости и удобствам. Раньше программист должен был знать только иерархию классов. Теперь иерархия классов может (и должна) не совпадать с иерархией атрибутов. Теперь программисту надо знать три вещи - иерархию классов, иерархию атрибутов и маппинг между ними. Во всех трех вещах могут быть ошибки. А поскольку в новом методе никакого контроля на этапе компиляции, то в новом методе ошибки будут неизбежно. Следовательно, потребуется большее время на изучение, написание, отладку и тестирования. Цитата:
Я посмотрел в существующий функционал насколько хватило терпения. Пипец!!! Цитата:
Про добавление - я помню документацию и помню твои слова, где было только "добавление классов". А вообще говоря, фреймворк должен успешно решать еще и задачи рефакторинга, изменения существующего функционала. Я писал об этом выше. Но фиг с ним. Давай пока останемся в рамках задачи "добавление класса в иерархию" Цитата:
![]() Да, никакой асинхронности. Да, я совершенно зря загорелся надеждой... Цитата:
Если "также как и сейчас", то нафига огород городить? А да, вспомнил, МС закрывает код базовых классов... Цитата:
но я уже говорил, что это не единственный способ. и далеко не оптимальный. и в самом деле! Цитата:
Цитата:
Цитата:
остальные не могут. а тут еще и доступ к изменению исходного кода закроют. я понимаю, что ты хочешь сказать. но так делают только внутри МС. Цитата:
еще раз извиняюсь за дебильную реализацию семейства классов от МС - но фреймворк должен работать и с такими примерами тоже. Цитата:
Я старался сделать минимальный код при помощи штатных средств. Последний раз редактировалось mazzy; 01.06.2017 в 21:52. |
|
![]() |
#3 |
Участник
|
Цитата:
Цитата:
в проекте на конструкторах не было main, который ВСЕ ЗНАЕТ. было main, которые знали о себе (как обычно)
в проекте на конструкторах не было contruct, который ВСЕ ЗНАЕТ. было два конструктора. каждый знает только о своем уровне и принимает решение своего уровня. Цитата:
в новом проекте на атрибутах действительно есть main, который должен знать обо всей иерархии. в проектике этого нет, потому что нет валидации входных данных. но в реальной жизни такая валидация обязательна.
Цитата:
Давай лучше поговорим о трудоемкости и об ответстенности за правильность результата.
Как бы ты оценил трудоемкость и удобность по сравнению со старым методом? Мое мнение: Через жопу по сравнению со старым конструкторским методом. Апгрейда при условии отсутствия breaking changes меньше. Поиска зависимостей - примерно такая же. Цитата:
Раньше программист должен был знать только иерархию классов.
Теперь иерархия классов может (и должна) не совпадать с иерархией атрибутов. Цитата:
Теперь программисту надо знать три вещи - иерархию классов, иерархию атрибутов и маппинг между ними.
Цитата:
Во всех трех вещах могут быть ошибки. А поскольку в новом методе никакого контроля на этапе компиляции, то в новом методе ошибки будут неизбежно.
Цитата:
Да, ортогональный
![]() Да, никакой асинхронности. Да, я совершенно зря загорелся надеждой... Цитата:
"Также как и сейчас" - это ты очень хорошо сказал.
Если "также как и сейчас", то нафига огород городить? Цитата:
Макс... Я понимаю что ты хочешь сказать. Но просто сделай проектик (чуть более сложный чем одноувроенвое семейство из трех классов) И покажи в нем что хочешь сказать.
|
|
|
За это сообщение автора поблагодарили: mazzy (5). |
Теги |
sysextension framework, sysoperation framework, как правильно, полезное |
|
|