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

Question

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

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

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

Answer 1

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.

Answer 2

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

Answer 3

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

Answer 4

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

Answer 5

В общем, publicметоды должны соответствовать очень высоким стандартам надежности (не приводить к сбою или повреждению данных из-за неправильного ввода) и осведомленности о безопасности (не позволять неожиданному вводу запускать эксплойт). Но для internal, protected, и private методы, часто будет разумным следовать более мягким стандартам, поскольку каждый имеет полный контроль над тем, какие входные данные может получать каждый метод.

Поскольку параметры, передаваемые в public метод (возможно, из внешнего источника) считается менее надежным, чем параметры, полученные из собственной сборки, методы, отмеченные как publicчасто анализаторы кода обрабатывают иначе, чем идентичные методы, отмеченные как internal. Как пример, с publicАнализатор может предупредить вас о том, что параметры метода не равны нулю. С участием internal методы, можно настроить анализатор так, чтобы nullпроверка. Или анализатор может самостоятельно определить, выполнив анализ потока всех исходных файлов для сборки, что null никогда не будет передан конкретному методу в качестве аргумента и, таким образом, определит, что нет необходимости проверять, является ли параметр null. Есть много других примеров того, как анализаторы лечат public и internal методы по-разному.

Правильно помечая классы, методы, свойства, поля, интерфейсы и т. Д. С помощью правильных модификаторов доступа, вы правильно сигнализируете анализаторам кода о своем намерении, а затем, взамен, анализатор может дать вам более актуальные предупреждающие сообщения и советы.

Answer 6

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

Answer 7

На очень простом языке:

Внутренний: вы сможете получить доступ только внутри сборки. например: вы создали AccountService.csproj с внутренним классом

      public interface IAccount{

  int TotalAmount(long accountID);
}
internal class Account:IAccount{
  
  public int TotalAmount(long accountID){
       ...
   }
}
public class Customer{
   
 public long accountID {get;set;}
 public int GetTotalAmount(){
   IAccount account = new Account();
   return account.TotalAmount(accountID)
 }
}

если вы ссылаетесь AccountService.csProj на BankService.csProj (BankService.csProj --> AccountService.csproj)

      Below are the properties that accessible in BankService.csProj    
Customer.GetTotalAmount() -- Accessible
IAccount.TotalAmount()    -- Accessible
Account.TotalAmount()     -- Not Accessible (as account class is internal)

Answer 8

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