DAX2009 аналог friend классов. Как сделать?

[Raven Melancholic]

В DAX2009 есть семейство классов, являющихся чем-то типа контрактов данных. В основе иерархии класс NodeContract. Сами эти классы хранят некоторые данные, доступ к которым производится при помощи методов parm*.
Сами эти классы-контракты не знают как получать данные, данными их заполняет другое семейство классов "создателей", в основе иерархии которых лежит класс NodeCreator. Эти классы создают и заполняют определенные NodeContract.
NodeContract создаются фабрикой классов (пока это один статический метод в классе NodeContract, но, вполне возможно, что переделаю на какой-то класс фабрики, а возможно и на семейство классов-фабрик). То же самое по поводу создания относится к семейству NodeCreator*.
Для тех, кто будет пользоваться семейством классов NodeContract* хотелось бы ограничить их создание только через использование семейства NodeCreator*.
В C++ я бы мог установить модификаторы friend. В C# разделением по файлам, мог бы определить видимость фабрик классов.
В DA2009 непонятно, как сделать так, чтобы классы NodeCreator* могли создавать экземпляры NodeContract*, но по другому их создать было бы нельзя (создать нельзя, использовать можно).
Если фабрики классов NodeContract* сделать публичными, то их может вызвать любой внешний код. Если сделать защищенными, то NodeCreator* их не сможет использовать.
Как сделать фабрики NodeContract* защищенными для всех, кроме NodeCreator*?
Понятно, что можно просто описать особенности в какой-то документации, но хотелось бы это реализовать на уровне кода.
Есть какие-то идеи?

[Raven Melancholic]

Пока на уровне идеи, но непонятно в реализации есть мысль в фабрике NodeContract в методе одним из параметров указывать NodeCreator (например _nodeCreator). И вызывать не создание NodeContract напрямую, а делать что-то типа _nodeCreator.makeContract*(NodeContract _qqq).
В этом случае, вызывающий код просто обязан будет использовать NodeContract. Но, на мой взгляд, тут получается достаточно большая взаимозависимость между классами контрактов данных и их создателями. Хотелось бы её избежать.
Опять же, при таком подходе хотелось бы сделать так, что NodeContract и NodeCreator знали друг о друге, а для внешнего кода был бы только один способ создания NodeContract - только через NodeCreator .

[db]

Цитата:

Сообщение от Raven Melancholic

Как сделать фабрики NodeContract* защищенными для всех, кроме NodeCreator*?
Понятно, что можно просто описать особенности в какой-то документации, но хотелось бы это реализовать на уровне кода.
Есть какие-то идеи?

сейчас не проверял, но как мне помнится DictClass.makeObject() на модификаторы доступа не смотрит. Т.е. сделать protected new () у NodeContract, а создавать их через фабрику в NodeCreator используя DictClass.makeObject()

Насколько допустимо пользоваться отражением и "особенностями" его работы решайте сами

[Logger]

Цитата:

Сообщение от db

сейчас не проверял, но как мне помнится DictClass.makeObject() на модификаторы доступа не смотрит. Т.е. сделать protected new () у NodeContract, а создавать их через фабрику в NodeCreator используя DictClass.makeObject()

Насколько допустимо пользоваться отражением и "особенностями" его работы решайте сами

Но ведь такой же способ может применить и тот код от которого хотят защититься.

[Raven Melancholic]

Цитата:

Сообщение от Logger

Но ведь такой же способ может применить и тот код от которого хотят защититься.

В топике я просто не полностью описал все подробности использования. В данном случае, мне нужно просто ограничить некоторые возможности для обычного использования/расширения классов. Если же кто-то начинает использовать отражение, то, наверное, он понимает что делает и сделает все как нужно.
Так что использовать отражение вполне можно, но как-то не совсем "душа лежит" к этому. Хотелось бы декларативно это сделать ,чтобы впоследствии те ,кто будет использовать классы сразу видели, что "вот оно как".

[Raven Melancholic]

Цитата:

Сообщение от db

создавать их через фабрику в NodeCreator используя DictClass.makeObject()

Ну new я, как правило, и так делаю protected. Более того, если для создания класса нужны (или по логике работы и предполагаемого дальнейшего расширения класса они могут понадобится) параметры, то и construct я так же защищаю, а предоставляю некие методы фабрик newЧегоТоТам.
Вообще, для решения моей задачи использование DictClass для создания объекта класса контракта в создателе идея неплохая. Только тогда побоку идут перекрестные ссылки, и BP начнет ругаться, что класс не используется ни прямо ни косвенно. Обойти и то и другое можно (например, в нужном создателе использовать в каком-то месте classStr(НужныйКонтракт)). В общем, спасибо за идею, если не найдется других возможностей, то такой подход неплохой кандидат.

[Logger]

Raven Melancholic, а зачем вам это ? Если не предполагалось такое использование, напишите в документации и в комментариях в исходном коде конструктора и все.
Зачем пытаться так жестко ограничить использующий код ? Все равно в Аксапте этого не сделаешь, всегда могут проломиться через DictClass.

[Raven Melancholic]

Цитата:

Сообщение от Logger

Зачем пытаться так жестко ограничить использующий код ? Все равно в Аксапте этого не сделаешь, всегда могут проломиться через DictClass.

Красоты хочется.
Я точно знаю, что этот код впоследствии буду использовать не я, а другие люди. И точно знаю, что этот механизм будет расширяться, так как пишу базовую логику, а наполнять её будут другие. Если им нужно будет "проломиться" через отражение, то они будут понимать, что и зачем делают. Если сделать все декларативно, то это для них сигнал "вот, обычно нужно делать так, если есть что-то нестандартное, то это на вашей совести".

[belugin]

1) написать свое правило Bp которое будет проверять правильное использование
2) сделать фасад из чистых интерфейсов и передавать простую документацию: "все кроме этого является деталью реализации"

[Raven Melancholic]

Цитата:

Сообщение от belugin

1) написать свое правило Bp которое будет проверять правильное использование
2) сделать фасад из чистых интерфейсов и передавать простую документацию: "все кроме этого является деталью реализации"

Интерфейсы используются. Действительно, можно указать в описании для заказчика что интерфейсы священны, а все остальное может меняться (например при исправлении ошибок или расширении механизма) - не рассчитывайте при своих модификациях на что-то кроме стабильности интерфейсов.
А вот про свое правило BP даже не подумал. С точки зрения идеологии DAX, чем BP не декларативное описание? Самое оно!