Показать сообщение отдельно
Старый 01.06.2017, 10:41   #73  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2925 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Цитата:
Сообщение от mazzy Посмотреть сообщение
да, можно передавать строковый тег.
но обычно стратегия определяется не menuItem, а datasource:
Ты сам выбрал этот пример. Можно и datasource - какая разница какого типа ключ - можно сделать и имя таблицы и ID.

Цитата:
собственно, как и раньше, имеем:
= эта штука работает на refleaction (со всеми вытекающими последствиями)
= вместо конструктора должен быть отдельный класс-запускач (дополнительно к адаптерам, хендлерам, хандлерам, хелперам добавляется еще и strategy)
Не нужно. Класс запускач и так у тебя был мы перерабатываем только создание.
Stragegy не обязательно. У тебя нет параметров в конструкторе (не путать с методом construct). Если параметры есть, достаточно добавить метод init(параметры).

Цитата:
= отдельный класс-запускач ломает систему перекрестных ссылок - теперь понять где что используется и как работает намного сложнее
Да, сложнее. Как и сложнее при наследовании вообще и при любой косвенности. Но если знать про такой паттерн достаточно смотреть перекрестные ссылки по атрибуту или иерархию классов.

Цитата:
Но:
= никакой параллельности или асинхронности в фреймворке не предполагается
Зачем она там?

Цитата:
= за уникальностью ключа должен следить сам программист
Так же как и в case - в 7 добавили проверку, но не для intrinsic finctions.

Цитата:
= ключ - строка, с позиционными значениями (почему не аксаптовский контейнер, не xml, не json, не другой сериализуемый объект? почему не использовать имя класса в качестве ключа?)
Имя класса, это строка вообще ты про SysPlugin а я про SysExtension. В последнем ключ это фактически что угодно что можно запихать в контейнер.

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

Цитата:
Другими словами, все равно есть длинный список параметров с заданными позициями. но у них нет дефолтных значений. Та-дам!
Это не параметры это ключ.

Цитата:
А весь конструктор должен быть в одном методе. Со всеми пересечениями кода. Та-дам!
Нет конструктор находится в каждом классе (не путать с методом construct). Что такое пересечения кода, я не знаю.

Цитата:
самое интересное, что эта штука не решает проблему подключения кода от разных производителей.
особенно, если разные производители добавлят классы с разными строками-ключами в середину иерархии. или добавят одинаковые ключи для разных классов.
Это решается так же как и любое пересечение имен в Ax - префиксами.

Цитата:
вопрос - какой? как? какова методика добавления класса в иерархию с атрибутами?
Я ж тебе пример привел.

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

Цитата:
и главное: а чем получившаяся конструкция по сути отличается от старых добрых конструкторов? (не считая дополнительной трудоемкости и отвалившихся перекрестных ссылок, конечно)
Перекрестные ссылки не отвалились, надо просто смотреть другие ссылики