Я хочу знать разницу между модификаторами видимости publicи internal.
Когда мы должны использовать internalв классе и когда public? Я не понимаю, когда должен быть метод publicили internal.
Я читал, что к нему internalможно получить доступ через publicсборку , а также можно использовать через сборку, в которой заключается разница.
Ответы:
public видно отовсюду.
internal виден только внутри сборки
Вы склонны использовать внутренние только для защиты внутренних API. Например, вы можете предоставить несколько перегрузок метода:
public int Add(int x, int y)
public int Add(int x,int y, int z)
Оба они вызывают внутренний метод
internal int Add(int[] numbers)
Затем вы можете усложнить метод, но «защитить» его с помощью фасадных методов, которые могут помочь программисту правильно вызвать метод. (Например, метод реализации с параметром массива может иметь произвольный предел значений.)
Также стоит отметить, что при использовании Reflection все методы могут быть вызваны независимо от их видимости. Еще один «взлом» для управления / получения доступа к внутренне скрытым API.
internalи всех методов public. Если вам нужна более высокая видимость, вы можете publicснова установить весь класс . Но я не уверен, предназначено ли это для такого использования. Итак, я продолжаю гуглить ... редактировать Et voilà, та же тема: stackoverflow.com/questions/9302236/…
internalполезно, когда вы хотите объявить член или тип внутри библиотеки DLL, а не вне ее ...
обычно, когда вы объявляете член, поскольку Publicвы можете получить к нему доступ из других DLL. но если вам нужно объявить что-то общедоступным только внутри вашей библиотеки классов, вы можете объявить это как Internal.
в формальном определении: внутренние элементы видны только внутри текущей сборки ...
internalтакже полезен при написании модульных тестов. InternalsVisibleToАтрибут давайте ваши тестовые сборки доступа внутренние методы в коде сборки. Т.е. вы можете тестировать методы, которые кажутся частными для внешнего мира, без использования отражения.
Публичный доступ также может быть доступен вне сборки. Поэтому, когда у вас есть класс, к которому не следует обращаться, каждый класс в сборке должен иметь к нему доступ, тогда internal - правильное решение. Если вам нужен внешний доступ, используйте public.
В общем, publicметоды должны соответствовать очень высоким стандартам надежности (не приводить к сбою или повреждению данных из-за неправильного ввода) и осведомленности о безопасности (не позволять неожиданному вводу запускать эксплойт). Но internal, protectedи privateметоды, он часто будет разумно следовать более расслабленный стандартам, так как один имеет полный контроль над тем, что входы каждый метод может получить.
Поскольку параметры, передаваемые publicметоду (возможно, из внешнего источника), считаются менее надежными, чем параметры, полученные из собственной сборки, методы, отмеченные как public, часто обрабатываются анализаторами кода иначе, чем идентичные методы, отмеченные как internal. Так же, как пример, с помощью publicметода анализатор может предупредить вас о проверке, что параметры метода не равны нулю. С помощью internalметодов можно настроить анализатор менее строгим в отношении nullпроверки. Или анализатор может самостоятельно определить, выполнив анализ потока всех исходных файлов для сборки, чтоnullникогда не будет передан конкретному методу в качестве аргумента и, таким образом, определит, что нет необходимости проверять, является ли параметр null. Есть много других примеров того, как анализаторы publicи internalметоды лечения по- разному.
Правильно помечая классы, методы, свойства, поля, интерфейсы и т. Д. С помощью правильных модификаторов доступа, вы правильно сигнализируете анализаторам кода о своем намерении, а затем, взамен, анализатор может дать вам более подходящие предупреждающие сообщения и советы.