внутренний против общественного В c#

Я хочу знать разницу между public и internal модификаторы видимости.

когда мы должны использовать internal на класс и когда public? Я смущен, когда метод должен быть public или internal.

Я читал, что internal можно получить доступ через сборку, в то время как public может также использоваться через сборку, где разница лежит.

6 77
c# .net

6 ответов:

public видно откуда угодно.

internal виден только внутри сборки

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

public int Add(int x, int y)
public int Add(int x,int y, int z)

оба из которых вызывают внутренний метод

internal int Add(int[] numbers)

вы можете поставить много сложности на метод, но "защитить" его с помощью фасадных методов, которые могут помочь программисту правильно вызвать метод. (Этот метод реализации с параметром массива может иметь произвольный предел значений, например.)

также стоит отметить, что с помощью отражения, любые и все методы вызываются независимо от их видимости. Еще один " хак " для управления/получения доступа к внутренне скрытым API.

90

internal полезно, когда вы хотите объявить член или тип внутри DLL, а не вне этого...
обычно, когда вы объявляете член как Public вы можете получить доступ к этому из других библиотек. но, если вам нужно было объявить что-то публичным только внутри вашей библиотеки классов, вы можете объявить его как Internal.
в формальном определении: внутренние элементы видны только внутри текущей сборки...

26

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

9

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

5

кроме того, свойства, обозначенные как internal бросит BindingExpression path error если используется для привязки данных в WPF. Так что они должны быть public для правильной работы, даже если привязка данных происходит в пределах одной сборки.

0

Если вы можете ссылаться на сборку извне , у вас есть область внутренних и общедоступных классов

-2