.NET의 인터페이스에 대한 "I"접두사 명명 규칙의 이유는 무엇입니까?


10

COM 이후로 "I"규칙이 사용 된 것을 알고 있지만 .NET 이전의 다른 모든 명명 규칙과 같이 왜 다시 고려되지 않았는지 이해하지 못했습니다.

소비를 현명하게, 인터페이스를 추상 클래스와 분리하는 유일한 것은 인터페이스가 곱셈 상속 될 수 있다는 것입니다. 그러나 Visual Studio 2003 이후에는 툴팁에 형식 서명이 표시되었으므로 폐기 된 다른 모든 헝가리어 표기법처럼 쓸모가 없습니다.

또한 Message상속 과 같은 동일한 이름으로 인터페이스의 기본 구현을 가질 수 있다고 생각 IMessage했지만 대부분의 .NET 라이브러리는 System.Collections.ReadOnlyCollectionBase대신 끝에 "Base"라는 단어를 추가했습니다. 그리고 이것은 더 의미 론적으로 의미가 있습니다.

COM interop은 또 다른 가능한 이유 인 것 같습니다. 그러나 생성하는 래퍼 클래스가 완벽하게 관용적 인 .NET 인 것처럼 보이지 않으므로 미적 고려 사항이 아닌 것 같습니다.

새로운 프로젝트 중 하나에서 컨벤션을 완전히 포기했으며 기분이 좋았습니다. 내가 놓친 것이 있습니까?


1
당신은 그것들을 성취하기 위해 인터페이스를 상속받지 않습니다.
Daniel Little

또한 List 및 ArrayList가 아닌 IList 및 List와 같은 기본 설정처럼 보입니다. 아마도 IList는 ListBase가 아니지만 실제로 ListInterface (인터페이스 유형이 아닌 List)이기 때문에 아마도 의미가 있습니다.
Daniel Little

@Lavinski In .NET IListList시퀀싱, 연속, 랜덤 액세스, 증가하는 컬렉션 의 일반적인 용어입니다 . 나는 F #이 에일리어싱 List에 맞았다 고 생각 한다 ResizeArray. 그것은 훨씬 더 설명적인 이름입니다. IList그럴 수도 있었 List으므로 그 이유도 아닌 것 같습니다.
Rei Miyasaka

2
: IBaseBall 및 IBaseBallBase는 BaseBallBase 및 BaseBallBaseBase (D 바보 예, 내가 아는)보다 나에게 더 의미
전자 MEE

@ e-MEE는 IRC 채팅 프로토콜의 인터페이스 또는 "정확히 기억하는 경우"의 약어 일 수있는 IIRC 일 것입니다.
Rei Miyasaka

답변:


12

접두사가 유용 할 때 이것이 유일하다고 생각합니다.

클래스와 인터페이스는 실제로 다른 의미론을 가지고 있으며 둘 다 유형이기 때문에 혼합하기 쉽습니다.
클래스 선언을 볼 때 클래스 에서 파생 된 내용구현 한 내용을 즉시 알 수 있습니다 .

public sealed class ActivityCollection : List<Activity>, 
    IList<Activity>, ICollection<Activity>, IEnumerable<Activity>, 
    IList, ICollection, IEnumerable

정의가 어떻게 생겼는지 이해하기가 더 어려울 것입니다

public sealed class ActivityCollection : ListClass<Activity>, 
    List<Activity>, Collection<Activity>, Enumerable<Activity>, 
    List, Collection, Enumerable

어떻게 전화 하겠어 ListClass? 분명히 ListBase그 자체로 사용할 수 있기 때문 이 아닙니다 .
따라서 방금 발명 한 문제를 해결하거나 .NET Framework 디자이너가하는 인터페이스와 클래스를 구분하는 접두사를 수정해야합니다.

또한 개인적으로 메소드 서명에서 인터페이스와 함께 작동한다는 것을 알 수있을 때 유용합니다.

public void PrintLines (IEnumerable<string> source)

그것은 내 머리에 신호와 같습니다 : 야, 나는 이것을 구현할 수 있습니다! 계약과 일치하는 방법으로 방법을 공급할 수 있습니다.

물론 그다지 중요하지 않다고 주장 할 수는 있지만 이것이 나에게 가치가있는 접두사를 만드는 작은 것 중 하나입니다. 인터페이스 작업을 지속적으로 수행하고 두 인터페이스를 쉽게 구분해야 할 때 IoC 컨테이너로 많은 코드를 작성할 때 특히 유용합니다.

그런데 인터페이스에만 .NET 유형 시스템의 접두사가 있습니다. 제네릭 형식 매개 변수를 잊지 마십시오.

public delegate TResult Func<in T, out TResult>(
    T arg
)

이것은 클래스와 다른 종류의 유형을 구별 할 수있는 매우 유용한 상황입니다.


2
"첫 번째 클래스는 상속이고 두 번째 클래스는 인터페이스"라는 것을 알면 쉽게 이해할 수 있습니다.
Saeed Neamati

3
이것은 그럴듯한 이유처럼 보입니다. Java는 단순히 키워드를 사용하여 목록을 명확하게함으로써 조금 더 잘 해결 한 것 같습니다 class Dog extends Mammal implements MailmanChaser. @Saeed는 아무것도 상속받지 않는 클래스를 가질 수 있으므로 목록의 첫 번째 유형은 실제로 기본 클래스가 아닌 인터페이스입니다.
Rei Miyasaka

굵은 글씨 부분에 대한 +1, 나는 접두사 기반의 규칙이 도움이되었을 것이다 다른 곳으로 생각할 수 있지만 :의 배타적 인 소유권 캡슐화 필드를 구분하는 int[](가변 타입의 또는 다른 개체)가 변이 수는 없지만 공유 및 공유 공유 소유권을 캡슐화하는 공유 int[]유형은 해당 유형이 돌연변이를 허용하더라도 아무도 돌연변이를 허용하지 않습니다.
supercat

6

나는 당신이 무엇을 놓치고 있다고 생각하지 않습니다. 그것은 단지 역사적인 습관입니다.

나는 당신에게도 동의하고 또한 해로운 영향을 미치지 않는 중소 규모의 프로젝트에서 'I'를 떨어 뜨 렸습니다.


2
이상한 점은 그들이 이것을 제외한 다른 모든 쓸모없는 관습을 실제로 버렸다는 것입니다. 역사도 그것을 설명하지 않습니다. 나는 그것이 단지 내부 정치에 불과한 것이 아니라면 여전히 이유가 있었을 것 같은 느낌이 들지만, 그럼에도 불구하고, 누군가가 내가 낙하하는 것에 대해 화를내는 이유를 실제로 볼 수는 없습니다.
Rei Miyasaka

2

인터페이스 및 클래스에 대한 Microsoft의 명명 지침에 따르면 유일한 이유 는 때때로 인터페이스 이름과 해당 클래스를 구현하는 클래스간에 충돌이 있기 때문이라고 생각합니다 . 이것은 인터페이스가 실제로 고기가 아니라 뼈대이며, 구현 자 클래스가 실제로 고기 (청사진 구현)라는 사실로 되돌아갑니다. 따라서, IAnimal은 동물 이 가지고 있는 것을 설명하는 반면, Animal은 동물 이 가지고 있는 것을 말할 수 있습니다 .

그러나 인터페이스에 Animal Base 를 사용 하고 수업에 Animal 을 사용할 수 있다는 점에서 개인적으로 완전히 동의합니다 .

반면에, 때때로 두 가지가 너무 많이 충돌하여 팀은 이미 내려진 결정에도 불구하고 추가 충돌을 방지하기위한 협약을 제공하기로 결정합니다. 예를 들어 ASP.NET MVC에서 부분 뷰레이아웃 (마스터 페이지)은 일반 와 비슷 하지만 다른 기능을 제공합니다. 따라서 Microsoft는 이름 지정에 밑줄을 사용하지 않는 것을 강조 했지만 밑줄이있는 레이아웃부분보기 를 밑줄로 표시합니다.


AnimalInterface대신에 무엇이 문제입니까 AnimalBase? 기본 클래스가 아니라 인터페이스입니다.
Scott Whitlock

3
그러나 AnimalInterface 대신 IAnimal의 문제점은 무엇입니까? 우리가 시작한 곳으로갔습니다. 일부 헝가리어 표기법이 유용하다는 것을 보여줍니다. 그것들을 모두 버리는 것은 (I와 T를 제외하고) 더 나은 시스템을 찾으려는 신중한 시도보다는 더 피케였습니다.
gbjbaanb

2
@ ScottWhitlock : 나에게는 IAnimal훨씬 더 읽기 쉽습니다 AnimalInterface. 간결한 이름은 간단한 짧은 규칙을 자주 발생하는 것에 사용할 수있는 경우를 제외하고 선호됩니다. 인터페이스도 그런 경우입니다.
maaartinus
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.