Показать сообщение отдельно
Старый 01.06.2017, 08:39   #68  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от belugin Посмотреть сообщение
В том что ты сделал: если задать сочетание Vend и MST это правильно что он молча это понимает и не ругается?
как я уже писал - этот проектик безумен настолько, насколько безумен исходный код, поставляемый майкрософтом.

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

Цитата:
Сообщение от belugin Посмотреть сообщение
Если допустимо, чтобы он ругался на такое сочетание. То для расширения черех SysExt надо пометить атрибутом новый класс.
да. это было понятно.

собственно, как и раньше, имеем:
= эта штука работает на refleaction (со всеми вытекающими последствиями)
= вместо конструктора должен быть отдельный класс-запускач (дополнительно к адаптерам, хендлерам, хандлерам, хелперам добавляется еще и strategy)
= отдельный класс-запускач ломает систему перекрестных ссылок - теперь понять где что используется и как работает намного сложнее

да, в platform update 7 они таки сделали.
  • new с параметрами
  • атрибут помечается строкой с разделителем ";", а не enum
  • в строке - позиционная запись параметров
  • в строке никаких дефолтных значений
  • в строке нет экранирующих символов чтобы экранировать ; в параметрах
  • никакого синтаксического сахара
  • строка похоже тупо проверяется на равенство - никаких регулярок, никаких критериев типа *?, никаких подстановок, никаких сравнений json-xml-структур.

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

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

А весь конструктор должен быть в одном методе. Со всеми пересечениями кода. Та-дам!

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

Цитата:
Сообщение от belugin Посмотреть сообщение
Для того, чтобы сделать расширяемым надо сделать атрибут
мы все еще на уровне "надо сделать атрибут"?
да, все уже в курсе.
вопрос - какой? как? какова методика добавления класса в иерархию с атрибутами? как добавлять в середину иерахии? как добавлять класс листом в иерархию? кто следит за уникальностью? что должно произойти с методом, который вычисляет ключ после добваления новый классов в иерархию?

насколько эта байда проще-легче, чем просто код конструкторов?

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


Цитата:
Сообщение от belugin Посмотреть сообщение
Снести все фабричные методы заменив на вызов фреймворка
вот-вот! именно!

Цитата:
Сообщение от belugin Посмотреть сообщение
Можно завтра в обед попробовать вместе это сделать
можно. спасибо. только у нас щас должен быть engineering complete.
боюсь, что на этой неделе я только урывками во время компиляции.

но тема - интересная.
в идеале нужен проект на семействе классов с иерархией.

Цитата:
Сообщение от skuull Посмотреть сообщение
вот конкретный пример.
спасибо.

Цитата:
Сообщение от skuull Посмотреть сообщение
И чтобы расширить это мне было достаточно
а) создать наследник пометив его другим атрибутом
б) создать новый menuItem с новым параметром.
Не все так плохо как хотелось бы
нет, конечно ))))))

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

и главное: а чем получившаяся конструкция по сути отличается от старых добрых конструкторов? (не считая дополнительной трудоемкости и отвалившихся перекрестных ссылок, конечно)
__________________
полезное на axForum, github, vk, coub.

Последний раз редактировалось mazzy; 01.06.2017 в 09:01.