Private, Protected, Public or Internal

[axm2017]

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

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

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

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

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

Что еще?

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