|
28.05.2017, 22:14 | #1 |
Участник
|
Код в месте, откуда происходит вызов наследников все равно придется менять, так как туда нужно будет передать новый добавленный атрибут для вызова нового наследника.
Шило на мыло. Тут мы добавляем новый атрибут, тут мы добавляем новый пункт свича для создания нужного наследника. Правильное добавление наследника никак не может повлиять на существующий код. Цитата:
Совершенно не оправданное ограничение МС. Приведите хотя бы один довод, почему в конструктор не должны передаваться параметры? Цитата:
Я говорю именно о месте, где производится инициализация объекта нового класса. В этом месте и в этот момент должно быть однозначно известно, какой наследник будет создан. И что это будет определять - атрибут или свич - совершенно все равно. Вопрос - зачем атрибут, если можно через свич легко и просто? |
|
|
За это сообщение автора поблагодарили: mazzy (2), Ace of Database (2). |
28.05.2017, 22:20 | #2 |
Участник
|
Цитата:
Цитата:
Я не говорю о полиморфизме.
Я говорю именно о месте, где производится инициализация объекта нового класса. В этом месте и в этот момент должно быть однозначно известно, какой наследник будет создан. И что это будет определять - атрибут или свич - совершенно все равно. Вопрос - зачем атрибут, если можно через свич легко и просто? |
|
29.05.2017, 03:08 | #3 |
Участник
|
Мне думается вот хорошее видео которое объясняет в целом концепцию
Антон Кекс — Как нам спасти Java https://www.youtube.com/watch?v=TSAlj04_tkA Вкратце - представьте что вас взяли архитектором в Микрософт. если вы предложите писать все через switch, то собственно возникнет вопрос нафиг вы тогда вообще нужны, switch и так все знают. Поэтому собственно идет расширение концепций(при чем принцип чем запутаннее, тем лучше). Вот кстати товарищ Мартин предлагает вообще использовать библиотеку Автофак для подобных вещей goshoom: IoC containers for extensibility если он сумеет продвинуть это, то в следующей версии будем разбираться уже с этим Кстати один из примеров который приводит Антон - это то что на каком то проекте куда они пришли довнедрять было вообще запрещено писать бизнес логику на Джава, все должно быть на SQL. когда начали разбираться откуда пошло это безумное требование, оказалось что если разрешить писать на Джава вещи типа сделать проводку, то получаются конструкции "когда класс создает другой класс чтобы через интерфейс вызвать третий" и т.п. и через некоторое время понять что происходит становится невозможно. SQL этого не позволяется, там собственно всегда можно увидеть что происходит с данными это кстати вспоминается когда приходится отлаживать что-то из Source Framework в Ах. |
|
|
За это сообщение автора поблагодарили: Ace of Database (2). |
29.05.2017, 11:52 | #4 |
Участник
|
В теории, разумеется, этого нет. Но Axapta - это не "теория". Это "экземпляр" теории Конкретная реализация, которая, разумеется, вводит свои собственные ограничения
Цитата:
classfactory.createClass(classId); передача параметров здесь не предусмотрена "в принципе". Все "параметры" поднимаются из unpack уже "потом". После инициализации Разумеется, пакетные задания - отдельный разговор, но, вообще-то, в Axapta довольно много разных обслуживающих процедур, которые требуют создание экземпляра класса для выполнения какого-либо анализа по структуре класса. Если у Вас в метод new передается какой-либо параметр, то есть риск получить Exception в момент создания экземпляра. Как следствие, весь функционал перестает работать Собственно, сделайте поиск по перекрестным ссылкам, где используется хотя бы classfactory.createClass() не говоря уже о DictClass.makeObject(). Удивитесь как много подобных вызовов Поэтому, чтобы не получить проблему "на ровном месте" в среде Axapta следует жестко придерживаться правила Никаких параметров в методах new Да, в большинстве случаев, у Вас проблем не будет, если Вы передадите параметр в new. Но однажды, в самый неподходящий момент, все "вдруг" перестанет работать
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... |
|
|
За это сообщение автора поблагодарили: mazzy (10). |
29.05.2017, 11:57 | #5 |
Участник
|
Цитата:
Сообщение от Владимир Максимов
Собственно, сделайте поиск по перекрестным ссылкам, где используется хотя бы classfactory.createClass() не говоря уже о DictClass.makeObject(). Удивитесь как много подобных вызовов
Поэтому, чтобы не получить проблему "на ровном месте" в среде Axapta следует жестко придерживаться правила Никаких параметров в методах new Да, в большинстве случаев, у Вас проблем не будет, если Вы передадите параметр в new. Но однажды, в самый неподходящий момент, все "вдруг" перестанет работать а давайте вернемся к исходному вопросу? Цитата:
Сообщение от ta_and
Здравствуйте.
У меня возникли чисто теоретические вопросы. 1. Какая цель создания экземпляров классов через расширенные атрибуты SysExtensionAppClassFactory::getClassFromSysAttribute( ? 2. Чем не устраивает старый дедовский способ construct ? 3. Как при создании экземпляра класса через расширенные атрибуты передать ему параметры в new? ПС. Я исхожу из принципа, что вызывающий класс и так ВСЕГДА должен знать какого наследника он создает. Зачем тогда городить огород и не вызывать просто создание нужного наследника? Типа свич лишний, давайте загрузим ядро, у него голова большая, пусть думает? Или у нас наследники классов растут как грибы, не успеваем исправлять конструктор, нужно через атрибуты это делать?... довести до ответов на исходные вопросы? |
|
01.06.2017, 14:22 | #6 |
Участник
|
И чтобы закрыть темы, прозвучавшие в этой ветке.
Цитата:
Сообщение от Владимир Максимов
передача параметров здесь не предусмотрена "в принципе". Все "параметры" поднимаются из unpack уже "потом". После инициализации
... Собственно, сделайте поиск по перекрестным ссылкам, где используется хотя бы classfactory.createClass() не говоря уже о DictClass.makeObject(). Удивитесь как много подобных вызовов Поэтому, чтобы не получить проблему "на ровном месте" в среде Axapta следует жестко придерживаться правила Никаких параметров в методах new Да, в большинстве случаев, у Вас проблем не будет, если Вы передадите параметр в new. Но однажды, в самый неподходящий момент, все "вдруг" перестанет работать И параметры в new вполне предусмотрены (я не знаю почему только 5 параметров), и сам фреймворк, заменяющий технологию конструкторов, использует конструкторы... Но пост мне очень понравился. Поскольку проблема действительно была. Не знаю осталась ли она сейчас. Надо полагать, исправили. https://www.facebook.com/photosm/pho...type=3&theater Последний раз редактировалось mazzy; 01.06.2017 в 14:43. |
|
01.06.2017, 15:08 | #7 |
Banned
|
Охренеть. Switch case 1, 2, 3, 4, 5. Наверное когда додумаются передавать массив параметров (array[]) тогда оформят это патентом.
|
|
01.06.2017, 19:07 | #8 |
Участник
|
Цитата:
Тут более занимательный вопрос, а откуда эти самые параметры вообще взялись-то? Если "знают" какие параметры передавать, то должны и "знать" о каком классе идет речь. Тогда DictClass.makeObject() становится как-то неуместным. Проще уж собственно экземпляр класса создать и его использовать. Зачем явно лишняя "прослойка"
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... Последний раз редактировалось Владимир Максимов; 01.06.2017 в 19:10. |
|
03.06.2017, 21:11 | #9 |
Участник
|
Цитата:
Для начала, чтобы не тратить время, определимся что такое конструктор. На мой взгляд, конструктор это то, что создает класс. В Аксе это метод new. Принято создавать статический метод construct, но, несмотря на название это все-таки не конструктор в общем понимании, а метод фабрики. Пример проблемы параметров в new очень простой (речь про DAX2009, то есть пока про атрибуты даже не вспоминаем). Создаем наследника RunBaseBatch в котором в new указываем параметры. Если запускаем этот класс через назначенный mtnuitem, то проблем нет. А теперь, представляем ситуацию, когда наш класс администратор хочет включить в пакетное задание в рамках журнала. Он запускает "Основное \ Запросы \ Пакетное задание. Создает новое задание, переходит в "Просмотр задач", создает новую строку и пытается выбрать класс обработки. И получает ошибку, причем непонятную - я встречал и "тип операнда не соответствует оператору" и "типы несовместимы" и другие и без всякого указания на класс, вызвавший проблему. На самом деле, даже не нужно создавать свой класс, MS, о нас позаботился и создал два такие класса. Если у Вас есть DAX2009 с Российской локализацией, включающей зарплату, то механизм создания журнала пакетного задания уже сломан из-за использования параметров в new. Пример тут: Создание пакетного задания DAX 2009 Последний раз редактировалось Raven Melancholic; 03.06.2017 в 21:17. |
|
Теги |
sysextension framework, sysoperation framework, как правильно, полезное |
|
|