.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 IList은 List시퀀싱, 연속, 랜덤 액세스, 증가하는 컬렉션 의 일반적인 용어입니다 . 나는 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.