«Внутренний» модификатор и принципы ООП

Question

Я слышал, что некоторые люди против использования модификатора internal для сокрытия классов и членов за пределами сборки, в которой они объявлены, потому что это нарушает основные принципы ООП. Это правда?

Answer 1

Это правда?

Нет, это не правда. Модификатор внутренней видимости имеет свои применения. Есть классы, которые вы не хотите использовать за пределами их содержащей сборки, но все же должны быть открытыми внутри сборки. Например, если вы разрабатываете API, могут существовать классы, которые вы не хотите показывать потребителям вашего API.

Answer 2

внутреннее ключевое слово позволяет разработчикам скрывать элементы сборки, если она используется другой сборкой.Например, в .NET Framework есть много внутренних типов, то есть они требуются только для использования внутренней сборки и не видны снаружи библиотеки.Это инкапсуляция на уровне сборки.

Answer 3

Ну, люди свободны иметь свое мнение. Я не уверен, как «внутренние» побеждают основные принципы ООП .. возможно, ссылка поможет мне оценить их позицию.

Я использую внутренние, чтобы скрыть типы, которые я не хочу, чтобы кто-либо вне сборки использовал. Это про-ООП на мой взгляд

• раскрыть поведение, но скрыть реализацию.
• использовать максимально ограниченный доступ

например. Я рефакторинг некоторого общего кода из 2 открытых типов; этот новый тип начинается как внутренний. Если какой-то клиент / тест не заставит меня увеличить видимость. Также я иногда использую его как временную читерскую программу, чтобы избежать написания тестов для некоторых типов (у всех открытых типов должны быть тесты). Это послужило мне хорошо.