Private, Protected, Public or Internal

[imir]

Цитата:

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

А ещё это освобождает вендора от неприятных раздумий типа «а не breaking ли change я сейчас пилю?»

Вот нашел специально, метод update() в таблице AssetLeaseIndexRateTable - [Hookable(false)]

Т.е. чтобы при апдейте записи по феншую через COC внутри транзакции что-то дописать, придется запрос делать в МС, тупо на табличный метод update? Либо МС избавился не только от неприятных раздумий, а в принципе.. либо одно из двух )

[axm2017]

Цитата:

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

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

На текущий момент при запуске ER отчета действует следующая схема, как понимаю:

Формат (format) находит в модели (model) структуру (root?), на основе которой он создан, и далее модель по структуре, находит соответствие (mapping) с данными системы.
Однако соответствий может быть несколько.

В настоящий момент система не позволяет выбрать и для корректной работы администратор ER обязан всегда поддерживать уникальность связки
format - mapping - structure of model.

Для каждого mapping должна быть своя структура иначе любой другой отчет и mapping с той же структурой приведет к проблеме.

На сколько знаю такие коллизии возможны в накладных (т.е. загрузишь отчеты а они будут работать только либо/либо) к примеру да и не только.

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

[axm2017]

Промежуточный итог как понимаю:

При задании доступа помни что чем меньше уровень доступа, тем проще анализировать код.

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

Internal используй если ты из MS и уже смирился с этим.

Юзай final если возможно

Что еще?

[Stitch_MS]

Цитата:

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

Вот нашел специально, метод update() в таблице AssetLeaseIndexRateTable - [Hookable(false)]

Т.е. чтобы при апдейте записи по феншую через COC внутри транзакции что-то дописать, придется запрос делать в МС, тупо на табличный метод update? Либо МС избавился не только от неприятных раздумий, а в принципе.. либо одно из двух )

В этом случае достаточно к системному событию onUpdating или onUpdated обработчик написать? Но да, в целом выглядит так, будто крупные новые фичи закрываются намеренно.

[belugin]

Цитата:

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

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

Internal используй если ты из MS и уже смирился с этим.

По-моему, если это внутренний код который никто снаружи не использует, то лучше все-таки по умолчанию private. Если кому-то надо будет поиспользовать - он сможет изменить модификатор на какой надо и это будет светиться на code review - "здесь сделан новый интерфейс, проверь, что все сделали правильно".

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

Если вы сделаете что-то protected, то надо рассматривать это как один из интерфейсов расширения. Если вы перекрываете метод с поведением в подклассе, то это как-правило нарушение LSP - обычно более логичная структура кода получается, если выделить абстрактный суперкласс и создать два наследника.

Официльные рекомендации для ISV - вот тут.

[axm2017]

Цитата:

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

По-моему, если это внутренний код который никто снаружи не использует, то лучше все-таки по умолчанию private.

Не использует != не будет использовать. Фичи вполне позволяют решать конфликтные ситуации (на сколько вижу практику того же МС). Private что был до D365 не предполагал что его нельзя поправить минимальными усилиями. В текущей реализации это уже честный private и неправильно выставленный он принесет больше проблем чем профита.

Сейчас для разработчиков бОльшая проблема недоступность к изменению функционала и время реакции.

Как пример те же закрытые командами МС модули. На сколько помню по циклам это около 4 недель ожидания если признают ошибкой (как понял из общения с коллегами это стандартный цикл разработки текущей версии, а далее cherry-picking на версии идущие к выпуску) и 4 недели * 4-5(?) если признают фичей (текущая версия а далее пройдет этапы до выпуска). Это недопустимо долго в реальности так как жить надо сейчас.

Именно по подобным примерам крайне отрицательно отношусь к необдуманному использованию internal без предоставления минимального интерфейса для коррекции вероятных ошибок алгоритмов.

ЗЫ и это кстати одна из причин почему мне нравится ER: как понимаю там цикл от обнаружения ошибки в логике ER конфигураций до выкладывания новой версии измеряется днями, часами. При этом клиент может сам поправить и спокойно жить в ожидании новой официальной версии.

[belugin]

1. Имел ввиду ситуацию, когда весь код не поставляется внешним потребителям. Например при кастомерской разработке

2. ER это, фактически, автоматизированный copy-on-write - конфигурации микрософт нельзя менять, но можно делать и подключать свои копии

[axm2017]

Цитата:

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

2. ER это, фактически, автоматизированный copy-on-write - конфигурации микрософт нельзя менять, но можно делать и подключать свои копии

Это если смотреть на уровне структуры внутренних данных (что кстати тоже интересно в плане архитектурного нафига так как насколько понимаю наследники не могут работать без предка, но при этом содержат данные достаточные для автономной работы).
На уровне пользователя, который не лезет в xml все выглядит как наследник.

[belugin]

Цитата:

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

выглядит как наследник.

Наследники не могут переопределять типы данных методов, например.

А тут копия - делай что хочешь.