Private, Protected, Public or Internal

[DSPIC]

Мне кажется - тут дискуссия слегка ушла в сторону. То, для чего нужны нужны final\private всем в той или иной мере понятно, и почитать об этом можно в любом учебнике.

Проблема поднята немного другая:

Цитата:

В компании принят подход при котором этот модификатор должен ставиться по умолчанию для методов

Цитата:

В D365 чей-то недальновидный мозг решил проставлять Private по умолчанию

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

Цитата:

Они могут себе попросить точку расширения, которой им не хватает.
Мы регулярно их делаем.

Вам там больше делать нечего? Или партнерам больше делать нечего, как тикет суппорты вам писать вместо 2-х минутного создания наследника?
А клиенты за это платят бешеные деньги и к нашему с вами счастью, пока не понимают - за какую чушь.

Закрыли код и понеслась фантазия: COC, ивенты, хукабл\не хукабл, рефлекшн в бизнесс-логике. Превратили систему в неуправляемую помойку... Точки расширения они делают регулярно. Деятели...

[mazzy]

Цитата:

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

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

Свергни тирана - получишь щастье?!

Неее. Это не так работает.
Программисты не заморачиваются там, где их не заморачивают типлиды.
Тимлиды и не думают там, где их не напрягают архитекторы и руководство.

А вот руководство как раз и не понимает кто платит за то, что делают их команды. Как не понимают то, какими свойствами должен обладать их продукт, чтобы за него платили.

Это ж не только private. Продавать только Azure версию, Seal классов, закрытые механизмы развертывания, сильно ограниченный доступ SQL...

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

Цитата:

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

То, для чего нужны нужны final\private всем в той или иной мере понятно, и почитать об этом можно в любом учебнике.

нееее. ни в каком учебние не раскрывается что делать пользователям ЗАКРЫТОГО фреймворка, когда вендор этого фреймворка использует эти модификаторы как полный невменько.

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


===============
добавлено:
и да!
полностью согласен, что вместо private почти всегда лучше использовать protected.
и полностью не согласен, что изменение модификатора по умолчанию хоть что-то изменит.
...хотя бы потому, что private-методы внутри Майкрософт не обязательно покрывать тестами.

[belugin]

Цитата:

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

Точки расширения они делают регулярно. Деятели...

Тут такая логическая цепочка: регулярные обновления => совместимость => органичение объема API.

При регулярных обновлениях надо быть обратно совместимым потому, что иначе расширения будут отваливаться. Теперь рассмотрим, что будет, если просто везде стаить public.

Вот, допустим кто-то написал

public void foo(string bar)
{
   ...- 
}

Теперь нам надо сделать дополнительный параметр.

public void foo(string bar, int baz)

- так делать нельзя. Расширение может вызывать этот метод и оно перестанет компилироваться и работать.

public void foo(string bar, int baz = 0)

Тут расширение из предыдущей фразы будет работать, но
1. Может быть расширение которое обернуло этот код и не прокидывает новый параметр
2. Если параметр baz логически обязательный, то все скомпилируется и сработает но неправильно. Фактически, это означает, что логически обязательный параметр вообще никак нельзя добавить без потери обратной совместимости.

public void foo(string bar)
{
     this.fooWithBaz(bar, 0);
}
public void fooWithBaz(string bar, int baz)

Так можно, но нельзя перестать вызывать foо в том месте, где он изначально вызывался, потому, что расширение может подписаться на вызовы foo или обернуть и тогда оно тихо перестанет работать.

Еще можно сделать disposable context - фактически передавать дополнительные данные через статический метод, но будут пролемы с рекурсией.

Можно изначально передавать параметры завернутые в parameter object.

A самое главное, от логически обязательного параметра не спасает ничего.

При этом всем этот метод в реальности, скорее всего, никакими расширениями не используется (потому, что большинство методов не используется) и делать его piblic значит просто закрыть себе возможность развития этого участка кода без какой бы то ни было выгоды для кого-то.