internal class Foo
{
public void Fee()
{
Debug.WriteLine("Fee");
}
internal void Fi()
{
Debug.WriteLine("Fi");
}
}
전체 클래스가 이미 내부이기 때문에 Fee ()와 Fi ()가 동등하게 액세스 할 수 있다고 생각합니다. 내가 뭔가를 간과하고 있습니까? 이와 같은 경우에 방법에 대해 공개 또는 내부를 선택할 이유가 있습니까?
답변
internal class Foo
선언은의 접근보다 우선합니다 public void Fee()
효과적으로 내부 만드는 방법을.
이 경우 메서드에 내부 및 공용을 사용하면 동일한 효과가 있습니다. 이와 같은 경우에 공용 메서드와 내부 메서드를 선택하는 유일한 이유는 선택하면 향후 버전에서 공용 클래스로 쉽게 전환 할 수 있기 때문입니다.
답변
대답에서 여기에 누락 된 유일한 것은 왜 이렇게 하시겠습니까?
일부 라이브러리에는 라이브러리 소비자가 만질 수없는 많은 클래스가 있지만 공용으로 표시된 인터페이스를 상속해야합니다. 예를 들어 IComparer 인터페이스를 상속하는 클래스가있는 라이브러리가 있지만 내부적으로 만 사용되며 라이브러리의 공개 측면을 어지럽히고 싶지 않습니다. 구현 된 Compare 함수를 내부로 표시하면 컴파일러에서 IComparer 인터페이스를 구현하지 않는다고 불평합니다.
그렇다면 인터페이스를 성공적으로 구현하는 동시에 라이브러리의 공개적인 측면에서 액세스 할 수 없도록하려면 어떻게해야합니까? 클래스를 내부로 표시하지만 구현 된 기능은 공용으로 표시하십시오.
답변
실제로-반사를 사용하는 경우 큰 차이가 있습니다. 특히 Silverlight는 액세스 권한이 있더라도 리플렉션을 통해 내부 메서드에 액세스하려고하면 매우 화가 날 수 있습니다. 일반 .NET에서는 작동하지만 Silverlight에서 코드가 작동하도록 메서드를 공개해야하는 경우를 보았습니다.
일반 .NET의 부분 신뢰에서도 동일한 것을 찾을 수 있습니다.
답변
내부 클래스가 인터페이스를 구현하기를 원할 때 차이가 있습니다. 일부 인터페이스의 구현 인 메서드는 Public이어야합니다.
답변
정확합니다. Fee와 Fi 모두 동일하게 액세스 할 수 있습니다.
CSharp 언어 사양 3.0에서 3.5.2 미만 :
프로그램 P 내에서 유형 T로 선언 된 중첩 멤버 M의 액세스 가능성 도메인은 다음과 같이 정의됩니다 (M 자체가 유형일 수 있음에 유의).
• 선언 된 M의 접근성이 public이면 M의 접근성 도메인은 T의 접근성 도메인이됩니다.
따라서 Fee가 공개로 선언 되더라도 Foo만큼 액세스 할 수 있습니다 (예 : 내부).
답변
msdn 문서 에 따르면 Foo 클래스는 어셈블리 외부에서 액세스 할 수 없으므로 메서드를 내부 또는 공용으로 표시하는 데 아무런 차이가 없습니다. InternalsVisibleTo 속성을 사용하여 차이를 만들지 않습니다.
답변
클래스가 내부 인 경우 내부 메서드 만 사용합니다. 마음이 바뀌고 수업을 공개하는 경우 텍스트 바꾸기 만하면 완료됩니다.
