Protected internal private
 

Задался тут вопросом, а насколько вообще ценны в дизайне ЯП модификаторы уровня доступности?
Полезность public/private разделения я явственно ощущаю. А вот дальше начинаются "а что если"...

Была ли у вас реальная производственная необходимость использовать internal, и есть ли у вас серьёзные аргументы против идеи убрать private, оставив protected?

Рассуждения исключительно умозрительные, про "мой проект сломается" не упоминать - считаем, что делаем новый высокоуровневый ЯП.

Ответ: Protected internal private
 

Да.

Нет, приват и протектед стоит разделять.

Ответ: Protected internal private
 

Нуууу, так не интересно, а аргументы где?

Ответ: Protected internal private
 

Все private и internal методы/поля/свойства/классы мы обфусцируем.

protected при наследовании часто использую, их никому не видно, кроме наследников.

internal на уровне dll видно, если проектируешь dll для кого-то, то делаешь интерналами все что не надо видеть всем кто "снаружи", но надо иметь доступ отовсюду в самой dll.

C точки зрения Unity - internal не сериализуется, хоть и видна всем. Не надо дополнительного атрибута NonSerialized для публичных полей.

Опять же с точки зрения Unity для методов событий типа Update использую protected чаще чем private потому, что тогда решарпер их не подкрашивает, что это метод не используется нигде.

Ответ: Protected internal private
 

protected очень даже нужен, когда надо работать с наследованием. Его отсутствие бы сильно усложнило (точнее, прокопипастило), вроде как, элементарный код.
Насчет internal уже не знаю, что сказать, но pax имхо довольно четко проаргументировал "за".
Где-то в собственных сырцах есть хороший пример для protected (на PascalABC.Net), только хз, где он.
p.s. да, я каннибал, а еще я люблю баловаться с инвалидами.

Ответ: Protected internal private
 

Прокомментирую сам себя еще, опять с точки зрения Unity. Пример: пишешь плагин, ложишь его в папку Plugins. Используешь internal по своему усмотрению. В обычных скриптах, которые не в Plugins, а в самом проекте, этих internal'ов не видно. Никто не получит доступ к неконтролируемому полю, если специально не зайдет и не отредактирует исходники плагина. Почему интерналы в плагинах не видно и так понятно - отдельная dll, компилирующаяся до остального кода.

Ответ: Protected internal private
 

Гм. В моей голове это всё звучало как-то стройнее... Попробуем ещё раз:
Если вам предложат писать на языке, в котором есть только public и protected, вас вырвет, или даже понравится? Ну так, чисто гипотетически.

Ответ: Protected internal private
 

Ну имхо это уже проблема языка и того, кто предложил, а не программиста, которому задачу решать надо. И ограничение это совсем другое, это не то, когда есть на выбор что использовать. Опять же, когда есть выбор, то все зависит от поставленных задач. Что было бы, если бы все приватные переменные классов Net Framework стали бы protected? Даже те, которые связаны с неконтролируемыми ресурсами. Все бы наследовались от этих классов и ломали бы все что можно.

Ответ: Protected internal private
 

я всё (почти) делаю public, и мне ок.

Ответ: Protected internal private
 

Солидарен, если это конечно не отдельная dll. Правда и тут бывают неудобства.
Вчера пытался положить отдельную текстуру на глаз(смотри тему c# + OpenGL) (тз изменили, приспичило несколько видов радужки), так оказалось что только на процедурных моделях можно это делать, а на загруженных нет. Капец это было проблемно, так как поле SubMeshes было protected readonly. Узнал я это только после того, как написал issues автору библиотеки, ибо в исходниках сложно было найти не зная что искать. Быстро ответил и изменил protected на public, через 6-8 часов.

Ответ: Protected internal private
 

А такое встречается довольно часто. Всё хорошо пока работаешь один.
Мне кажется эти искусственные ограничения как раз придуманы для ситуаций когда кода один кодер завещет другому код и как-бы объясняет:
Вот это наследуй и перегружай (protected)
А вот эту фигню лучше не трогать (private)

Но это всё усложняет. Заведомо предугадать как будут перегружать твои классы и всё при этом учесть очень не простая задача.

Ответ: Protected internal private
 

И работаешь наверное с проектом один?)

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

Ответ: Protected internal private
 

да

Ответ: Protected internal private
 

Ну коммент я выше дописал.

Ответ: Protected internal private
 

Приведу пару примеров:

1. Все открыто, ты меняешь какую-то одну переменную открытую, проблем особо не замечаешь. Потом работаешь дальше, начинают какие-то странные проблемы появляться. С чем это связано? А вот автор той dll не подразумевал, что кто-то будет менять эти переменные, это его "магические числа" что только с ними все работает. И в результате тратишь ппц сколько времени, на то чтобы разобраться.

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