Private, Protected, Public or Internal

[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 конфигураций до выкладывания новой версии измеряется днями, часами. При этом клиент может сам поправить и спокойно жить в ожидании новой официальной версии.