AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
DAX
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 07.11.2015, 15:06   #1  
Raven Melancholic is offline
Raven Melancholic
Участник
Аватар для Raven Melancholic
Самостоятельные клиенты AX
Лучший по профессии 2015
 
2,158 / 1286 (47) ++++++++
Регистрация: 21.03.2005
Адрес: Москва-Петушки
DAX2009 аналог friend классов. Как сделать?
В DAX2009 есть семейство классов, являющихся чем-то типа контрактов данных. В основе иерархии класс NodeContract. Сами эти классы хранят некоторые данные, доступ к которым производится при помощи методов parm*.
Сами эти классы-контракты не знают как получать данные, данными их заполняет другое семейство классов "создателей", в основе иерархии которых лежит класс NodeCreator. Эти классы создают и заполняют определенные NodeContract.
NodeContract создаются фабрикой классов (пока это один статический метод в классе NodeContract, но, вполне возможно, что переделаю на какой-то класс фабрики, а возможно и на семейство классов-фабрик). То же самое по поводу создания относится к семейству NodeCreator*.
Для тех, кто будет пользоваться семейством классов NodeContract* хотелось бы ограничить их создание только через использование семейства NodeCreator*.
В C++ я бы мог установить модификаторы friend. В C# разделением по файлам, мог бы определить видимость фабрик классов.
В DA2009 непонятно, как сделать так, чтобы классы NodeCreator* могли создавать экземпляры NodeContract*, но по другому их создать было бы нельзя (создать нельзя, использовать можно).
Если фабрики классов NodeContract* сделать публичными, то их может вызвать любой внешний код. Если сделать защищенными, то NodeCreator* их не сможет использовать.
Как сделать фабрики NodeContract* защищенными для всех, кроме NodeCreator*?
Понятно, что можно просто описать особенности в какой-то документации, но хотелось бы это реализовать на уровне кода.
Есть какие-то идеи?
Старый 07.11.2015, 15:19   #2  
Raven Melancholic is offline
Raven Melancholic
Участник
Аватар для Raven Melancholic
Самостоятельные клиенты AX
Лучший по профессии 2015
 
2,158 / 1286 (47) ++++++++
Регистрация: 21.03.2005
Адрес: Москва-Петушки
Пока на уровне идеи, но непонятно в реализации есть мысль в фабрике NodeContract в методе одним из параметров указывать NodeCreator (например _nodeCreator). И вызывать не создание NodeContract напрямую, а делать что-то типа _nodeCreator.makeContract*(NodeContract _qqq).
В этом случае, вызывающий код просто обязан будет использовать NodeContract. Но, на мой взгляд, тут получается достаточно большая взаимозависимость между классами контрактов данных и их создателями. Хотелось бы её избежать.
Опять же, при таком подходе хотелось бы сделать так, что NodeContract и NodeCreator знали друг о друге, а для внешнего кода был бы только один способ создания NodeContract - только через NodeCreator .

Последний раз редактировалось Raven Melancholic; 07.11.2015 в 15:23.
Старый 07.11.2015, 17:19   #3  
db is offline
db
Роман Долгополов (RDOL)
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
 
393 / 692 (24) +++++++
Регистрация: 01.04.2004
Адрес: Москва
Цитата:
Сообщение от Raven Melancholic Посмотреть сообщение
Как сделать фабрики NodeContract* защищенными для всех, кроме NodeCreator*?
Понятно, что можно просто описать особенности в какой-то документации, но хотелось бы это реализовать на уровне кода.
Есть какие-то идеи?
сейчас не проверял, но как мне помнится DictClass.makeObject() на модификаторы доступа не смотрит. Т.е. сделать protected new () у NodeContract, а создавать их через фабрику в NodeCreator используя DictClass.makeObject()

Насколько допустимо пользоваться отражением и "особенностями" его работы решайте сами
За это сообщение автора поблагодарили: Raven Melancholic (10).
Старый 07.11.2015, 18:20   #4  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от db Посмотреть сообщение
сейчас не проверял, но как мне помнится DictClass.makeObject() на модификаторы доступа не смотрит. Т.е. сделать protected new () у NodeContract, а создавать их через фабрику в NodeCreator используя DictClass.makeObject()

Насколько допустимо пользоваться отражением и "особенностями" его работы решайте сами
Но ведь такой же способ может применить и тот код от которого хотят защититься.
За это сообщение автора поблагодарили: Raven Melancholic (2).
Старый 07.11.2015, 18:22   #5  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Raven Melancholic, а зачем вам это ? Если не предполагалось такое использование, напишите в документации и в комментариях в исходном коде конструктора и все.
Зачем пытаться так жестко ограничить использующий код ? Все равно в Аксапте этого не сделаешь, всегда могут проломиться через DictClass.
Старый 07.11.2015, 21:19   #6  
Raven Melancholic is offline
Raven Melancholic
Участник
Аватар для Raven Melancholic
Самостоятельные клиенты AX
Лучший по профессии 2015
 
2,158 / 1286 (47) ++++++++
Регистрация: 21.03.2005
Адрес: Москва-Петушки
Цитата:
Сообщение от db Посмотреть сообщение
создавать их через фабрику в NodeCreator используя DictClass.makeObject()
Ну new я, как правило, и так делаю protected. Более того, если для создания класса нужны (или по логике работы и предполагаемого дальнейшего расширения класса они могут понадобится) параметры, то и construct я так же защищаю, а предоставляю некие методы фабрик newЧегоТоТам.
Вообще, для решения моей задачи использование DictClass для создания объекта класса контракта в создателе идея неплохая. Только тогда побоку идут перекрестные ссылки, и BP начнет ругаться, что класс не используется ни прямо ни косвенно. Обойти и то и другое можно (например, в нужном создателе использовать в каком-то месте classStr(НужныйКонтракт)). В общем, спасибо за идею, если не найдется других возможностей, то такой подход неплохой кандидат.
Старый 07.11.2015, 21:29   #7  
Raven Melancholic is offline
Raven Melancholic
Участник
Аватар для Raven Melancholic
Самостоятельные клиенты AX
Лучший по профессии 2015
 
2,158 / 1286 (47) ++++++++
Регистрация: 21.03.2005
Адрес: Москва-Петушки
Цитата:
Сообщение от Logger Посмотреть сообщение
Но ведь такой же способ может применить и тот код от которого хотят защититься.
В топике я просто не полностью описал все подробности использования. В данном случае, мне нужно просто ограничить некоторые возможности для обычного использования/расширения классов. Если же кто-то начинает использовать отражение, то, наверное, он понимает что делает и сделает все как нужно.
Так что использовать отражение вполне можно, но как-то не совсем "душа лежит" к этому. Хотелось бы декларативно это сделать ,чтобы впоследствии те ,кто будет использовать классы сразу видели, что "вот оно как".
Старый 07.11.2015, 21:33   #8  
Raven Melancholic is offline
Raven Melancholic
Участник
Аватар для Raven Melancholic
Самостоятельные клиенты AX
Лучший по профессии 2015
 
2,158 / 1286 (47) ++++++++
Регистрация: 21.03.2005
Адрес: Москва-Петушки
Цитата:
Сообщение от Logger Посмотреть сообщение
Зачем пытаться так жестко ограничить использующий код ? Все равно в Аксапте этого не сделаешь, всегда могут проломиться через DictClass.
Красоты хочется.
Я точно знаю, что этот код впоследствии буду использовать не я, а другие люди. И точно знаю, что этот механизм будет расширяться, так как пишу базовую логику, а наполнять её будут другие. Если им нужно будет "проломиться" через отражение, то они будут понимать, что и зачем делают. Если сделать все декларативно, то это для них сигнал "вот, обычно нужно делать так, если есть что-то нестандартное, то это на вашей совести".
За это сообщение автора поблагодарили: mazzy (2), ice321i (1).
Старый 07.11.2015, 23:08   #9  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
1) написать свое правило Bp которое будет проверять правильное использование
2) сделать фасад из чистых интерфейсов и передавать простую документацию: "все кроме этого является деталью реализации"
За это сообщение автора поблагодарили: mazzy (2), Raven Melancholic (10).
Старый 07.11.2015, 23:50   #10  
Raven Melancholic is offline
Raven Melancholic
Участник
Аватар для Raven Melancholic
Самостоятельные клиенты AX
Лучший по профессии 2015
 
2,158 / 1286 (47) ++++++++
Регистрация: 21.03.2005
Адрес: Москва-Петушки
Цитата:
Сообщение от belugin Посмотреть сообщение
1) написать свое правило Bp которое будет проверять правильное использование
2) сделать фасад из чистых интерфейсов и передавать простую документацию: "все кроме этого является деталью реализации"
Интерфейсы используются. Действительно, можно указать в описании для заказчика что интерфейсы священны, а все остальное может меняться (например при исправлении ошибок или расширении механизма) - не рассчитывайте при своих модификациях на что-то кроме стабильности интерфейсов.
А вот про свое правило BP даже не подумал. С точки зрения идеологии DAX, чем BP не декларативное описание? Самое оно!
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Иерархия классов, как обновить? Raven Melancholic DAX: Программирование 3 11.05.2015 19:49
Сделать левый join или сделать динамическую группировку в GRID kadet DAX: Программирование 10 12.03.2013 12:07
В DAX2009 забыли сделать сторно по проектам через журнал ГК. Pustik DAX: Программирование 1 05.03.2011 00:07
Как сделать фильтр по группе пользователей? Zabr DAX: Программирование 12 08.04.2009 11:40
Заумный отчет по ОС, как сделать? Бриллиантик DAX: Программирование 13 09.07.2008 16:36
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

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

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 18:59.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.