В эту интересную ветку уже было добавлено довольно много ответов, однако я не совсем нашел реальную причину, почему это поведение так, как есть. Позвольте мне попробовать:
В те дни
Где-то между Smalltalk в 80-х и Java в середине 90-х созрела концепция объектной ориентации. Сокрытие информации, изначально не рассматриваемое как концепция, доступная только для ОО (впервые упомянутое в 1978 г.), было введено в Smalltalk, поскольку все данные (поля) класса являются частными, все методы являются открытыми. Во время многих новых разработок ОО в 90-х годах Бертран Мейер попытался формализовать большую часть концепций ОО в своей знаковой книге Построение объектно-ориентированного программного обеспечения (OOSC), которая с тех пор считается (почти) окончательной ссылкой на концепции ОО и проектирование языка. ,
В случае частной видимости
Согласно Мейеру, метод должен быть доступен для определенного набора классов (стр. 192-193). Это, очевидно, дает очень высокую степень детализации сокрытия информации, следующая функция доступна для classA и classB и всех их потомков:
feature {classA, classB}
methodName
В случае private
он говорит следующее: без явного объявления типа как видимого для его собственного класса, вы не можете получить доступ к этой функции (метод / поле) в квалифицированном вызове. Т.е. если x
это переменная, x.doSomething()
не допускается. Безусловный доступ разрешен, конечно, внутри самого класса.
Другими словами: чтобы разрешить доступ экземпляру того же класса, вы должны явно разрешить доступ к методу этого класса. Это иногда называют частным экземпляром против частного класса.
Частный экземпляр в языках программирования
Я знаю по крайней мере два языка, которые в настоящее время используются, которые используют скрытие частной информации экземпляра, а не скрытие частной информации класса. Одним из них является Eiffel, язык, разработанный Мейером, который доводит ОО до предела. Другой - Ruby, гораздо более распространенный язык в наши дни. В Ruby private
означает «личное для данного экземпляра» .
Выбор для языкового дизайна
Было высказано предположение, что разрешение экземпляра private будет сложным для компилятора. Я так не думаю, так как достаточно просто разрешить или запретить квалифицированные вызовы методов. Если для частного метода, doSomething()
разрешено иx.doSomething()
не , разработчик языка эффективно определил доступность только для экземпляра для закрытых методов и полей.
С технической точки зрения, нет причин выбирать тот или иной путь (особенно если учесть, что Eiffel.NET может делать это с IL, даже с множественным наследованием, нет внутренней причины не предоставлять эту функцию).
Конечно, это дело вкуса, и, как уже упоминали другие, довольно сложно написать некоторые методы без возможности видимости на уровне класса частных методов и полей.
Почему C # допускает только инкапсуляцию классов, а не инкапсуляцию экземпляров
Если вы посмотрите на интернет-потоки на инкапсуляцию экземпляра (термин, который иногда используется для обозначения того факта, что язык определяет модификаторы доступа на уровне экземпляра, а не на уровне класса), концепция часто осуждается. Однако, учитывая, что некоторые современные языки используют инкапсуляцию экземпляров, по крайней мере, для модификатора частного доступа, вы можете думать, что это может быть и полезно в современном мире программирования.
Тем не менее, C #, по общему признанию, больше всего смотрел на C ++ и Java из-за своего языкового дизайна. Хотя Eiffel и Modula-3 также были в картине, учитывая, что многие функции Eiffel отсутствуют (множественное наследование), я считаю, что они выбрали тот же маршрут, что и Java и C ++, когда дело дошло до модификатора частного доступа.
Если вы действительно хотите знать, почему вы должны попытаться заполучить Эрика Липперта, Кшиштофа Квалину, Андерса Хейлсберга или любого другого, кто работал над стандартом C #. К сожалению, я не смог найти однозначного примечания в аннотированном языке программирования C # .