명명 문제 : "문제"의 이름이 "뭔가"로 바뀌어야합니까? [닫은]

Clean Code의 이름에 대한 Bob Uncle 장의 이름은 주로 헝가리 표기법에 관한 이름의 인코딩을 피하는 것이 좋습니다. 또한 I인터페이스 에서 접두사를 제거하는 것에 대해 구체적으로 언급 하지만 이에 대한 예제는 표시하지 않습니다.

다음을 가정 해 봅시다.

• 인터페이스 사용은 주로 의존성 주입을 통해 테스트 가능성을 달성하는 것입니다.
• 대부분의 경우 단일 구현 자와 단일 인터페이스를 갖습니다.

예를 들어이 두 가지의 이름은 무엇입니까? Parser그리고 ConcreteParser? Parser그리고 ParserImplementation?

public interface IParser {
    string Parse(string content);
    string Parse(FileInfo path);
}

public class Parser : IParser {
     // Implementations
}

아니면 이와 같은 단일 구현 사례 에서이 제안을 무시해야합니까?

"Uncle Bob"을 포함하여 많은 사람들 I이 인터페이스의 접두사 로 사용하지 말 것을 권장하지만 그렇게하는 것은 C #에서 잘 확립 된 전통입니다. 일반적으로 피해야합니다. 그러나 C #을 작성하는 경우 해당 언어의 규칙을 따르고 사용해야합니다. 그렇게하지 않으면 코드를 읽으려고하는 C #에 익숙한 다른 사람과 혼동 될 수 있습니다.

인터페이스는 중요한 논리적 개념이므로 인터페이스에는 일반 이름이 있어야합니다. 그래서 나는 오히려

interface Something
class DefaultSomething : Something
class MockSomething : Something

...보다

interface ISomething
class Something : ISomething
class MockSomething : ISomething

후자는 몇 가지 문제가 있습니다.

1. 무언가는 ISomething의 한 가지 구현 일 뿐이지 만, 그것이 마치 특별한 것처럼 일반적인 이름을 가진 것입니다.
2. MockSomething은 무언가에서 파생 된 것처럼 보이지만 ISomething을 구현합니다. 어쩌면 MockISomething이라는 이름이 있어야하지만 야생에서는 결코 본 적이 없습니다.
3. 리팩토링이 더 어렵다. 무언가가 지금 클래스이고 나중에 인터페이스를 소개해야한다는 것을 알게되면 유형이 구체적 클래스인지 추상 클래스인지 인터페이스인지 클라이언트에게 투명해야하기 때문에 해당 인터페이스의 이름이 동일해야합니다. . 문제가 발생합니다.

이것은 단지 명명 규칙에 관한 것이 아닙니다 . C #은 다중 상속을 지원하지 않으므로 이러한 헝가리 표기법의 레거시 사용은 기본 클래스에서 상속하고 하나 이상의 인터페이스를 구현할 때 유용한 이점을 제공합니다. 그래서 이건...

class Foo : BarB, IBarA
{
    // Better...
}

... 이것보다 바람직하다 ...

class Foo : BarB, BarA
{
    // Dafuq?
}

IMO

아니, 아니.

명명 규칙은 Bob 아저씨 팬덤의 기능이 아닙니다. 언어, c # 등의 함수가 아닙니다.

그것들은 코드베이스의 기능입니다. 상점의 훨씬 적은 범위까지. 다시 말해, 코드베이스의 첫 번째는 표준을 설정합니다.

그래야 결정을 내릴 수 있습니다. 그 후에는 일관성이 있습니다. 누군가 불일치하기 시작하면 너프 총을 빼내고 회개 할 때까지 문서를 업데이트하도록합니다.

새 코드베이스를 읽을 때 I언어에 관계없이 접두사가 표시되지 않으면 괜찮습니다. 모든 인터페이스에서 하나를 보면 괜찮습니다. 때때로 하나를 보게되면 누군가가 지불하게됩니다.

코드 기반을 위해이 선례를 설정하는 희소 한 맥락에서 자신을 발견하면 이것을 고려해야합니다.

고객 클래스로서 나는 내가 말하고있는 것을 망설이지 않을 권리를 보유합니다. 필요한 것은 이름과 그 이름에 대해 부를 수있는 것들의 목록입니다. 내가 그렇게 말하지 않으면 변경되지 않을 수 있습니다. 나는 그 부분을 소유한다. 내가 말하고있는 것은 인터페이스 여부와 관계없이 내 부서가 아닙니다.

I그 이름으로 몰래 들어가면 고객은 신경 쓰지 않습니다. 이 없으면 I클라이언트는 신경 쓰지 않습니다. 그것이 말하는 것은 구체적 일 수 있습니다. 그렇지 않을 수도 있습니다. new어떤 식 으로든 호출하지 않기 때문에 아무런 차이가 없습니다. 클라이언트로서, 나는 모른다. 알고 싶지 않습니다.

이제 자바에서도 코드를 보는 코드 원숭이로서 이것이 중요 할 수 있습니다. 결국, 구현을 인터페이스로 변경 해야하는 경우 클라이언트에게 알리지 않고 그렇게 할 수 있습니다. I전통 이 없으면 이름을 바꾸지 못할 수도 있습니다. 소스가 바이너리를 신경 쓰지 않아도 클라이언트를 다시 컴파일해야하기 때문에 문제가 될 수 있습니다. 이름을 변경하지 않은 경우 놓치기 쉬운 것.

아마도 그것은 당신에게 문제가되지 않을 것입니다. 아마. 그렇다면 치료해야 할 좋은 이유입니다. 그러나 책상 장난감을 좋아한다고해서 우리가 맹목적으로 수행 해야하는 방식이기 때문에 맹목적으로해야한다고 주장하지 않습니다. 타당한 이유가 있거나 상관하지 않습니다.

영원히 함께 사는 것이 아닙니다. 어디에서나 '문제'를 고치기 위해 준비하지 않으면 특정 정신에 맞지 않는 코드베이스에 대해 헛소리를 내지 않습니다. 당신이 타당한 이유가 없다면, 균일성에 대한 최소한의 저항의 길을 택해서는 안됩니다. 나에게 순응을 설교하지 마십시오. 더 좋은 일이 있습니다.

여기에 관련된 Java와 C # 사이에는 작은 차이가 있습니다. Java에서 모든 멤버는 기본적으로 가상입니다. C #에서는 인터페이스 멤버를 제외한 모든 멤버가 기본적으로 봉인됩니다.

이에 관한 가정은 지침에 영향을 미칩니다. Java에서는 모든 공개 유형이 Liskov의 대체 원칙 [1]에 따라 비 최종으로 간주되어야합니다. 구현이 하나 뿐인 경우 클래스 이름을 지정합니다 Parser. 여러 구현이 필요한 경우 클래스를 동일한 이름의 인터페이스로 변경하고 구체적인 구현의 이름을 설명으로 변경하면됩니다.

C #에서 주된 가정은 클래스를 가져올 때 (이름이로 시작되지 않음 I) 원하는 클래스라는 것입니다. 100 % 정확하지는 않습니다. 일반적인 카운터 예제는 Stream(실제로 인터페이스이거나 몇 개의 인터페이스 여야 했음) 같은 클래스가 될 것입니다. 모든 사람은 다른 언어의 고유 한 지침과 배경을 가지고 있습니다. Base추상 클래스를 나타 내기 위해 상당히 널리 사용되는 접미사 와 같은 다른 예외도 있습니다 . 인터페이스와 마찬가지로 유형이 다형성이어야한다는 것을 알고 있습니다.

또한 인터페이스를 추상 클래스로 만들지 않고 해당 인터페이스와 관련된 기능에 I 접두사가 아닌 이름을 남겨두면 유용한 유용성 기능이 있습니다 (C #의 클래스 다중 상속이 없기 때문에 상처를 입을 수 있음). LINQ IEnumerable<T>는 인터페이스와 Enumerable해당 인터페이스에 적용되는 메소드의 저장소로 사용됩니다. 인터페이스에는 메소드 구현도 포함될 수있는 Java에서는 필요하지 않습니다.

궁극적으로 I접두사는 C # 세계에서 널리 사용되며 확장으로 .NET 세계 (대부분의 .NET 코드는 C #으로 작성되므로 대부분의 공용 인터페이스에 대한 C # 지침을 따르는 것이 좋습니다)입니다. 이것은 거의 확실 하게이 표기법을 따르는 라이브러리 및 코드로 작업하고 있음을 의미하며 불필요한 혼란을 방지하기 위해 전통을 채택하는 것이 합리적입니다. 접두사를 생략하면 코드가 더 좋아질 것입니다 :)

밥 삼촌의 추론은 다음과 같다고 생각합니다.

IBanana바나나의 추상적 개념입니다. 보다 나은 이름을 가지지 않는 구현 클래스가있을 경우 Banana추상화는 전혀 의미 가 없으므로 인터페이스를 삭제하고 클래스를 사용해야합니다. 더 나은 이름 (예 : LongBanana또는 AppleBanana)이 있으면 Banana인터페이스 이름으로 사용하지 않을 이유가 없습니다 . 따라서 I접두사를 사용하면 쓸모없는 추상화가 생겨 코드를 이해하기 어렵게 만들 수 있습니다. 엄격한 OOP는 항상 인터페이스에 대해 코드를 작성 I하므로 유형 에서 접두사 가 표시되지 않는 유일한 위치 는 생성자에 있습니다.

이것을 샘플 IParser인터페이스에 적용 하면 추상화가 전적으로 "무의미한"영역에 있음을 분명히 알 수 있습니다. 어느 파서 (예를 들면의 구체적인 구현에 대한 구체적인 뭔가있다 JsonParser, XmlParser...), 아니면 그냥 클래스를 사용해야은. "기본 구현"과 같은 것은 없습니다 (일부 환경에서는 COM이 의미가 있습니다). 특정 구현이 있거나 "기본"에 대한 추상 클래스 또는 확장 메소드를 원합니다. 그러나 C #에서는 코드베이스에서 I-prefix를 이미 생략하지 않은 한 유지하십시오. 다음과 같은 코드를 볼 때마다 정신적으로 메모하십시오. class Something: ISomething누군가 YAGNI를 따르고 합리적인 추상화를 작성하는 데 능숙하지 않다는 것을 의미합니다.

[1]-기술적으로 이것은 Liskov의 논문에서 구체적으로 언급되지는 않았지만 원래 OOP 논문의 기초 중 하나이며 Liskov를 읽었을 때 그녀는 이것에 도전하지 않았습니다. 덜 엄격한 해석 (대부분의 OOP 언어가 사용하는 해석)에서, 대체 용 (예 : 최종 / 밀봉되지 않은) 공용 유형을 사용하는 코드는 해당 유형의 적합한 구현에서 작동해야합니다.

예를 들어이 두 가지의 이름은 무엇입니까? 파서와 콘크리트 파서? 파서 및 파서 구현?

이상적인 세상에서, 당신은 당신의 이름을 속기 ( "I ...")로 접두사로 붙이지 말고 단순히 이름이 개념을 표현하게하여야합니다.

이 ISomething 규칙을 사용하면 "Dollar"클래스가 필요할 때 "IDollar"개념을 정의 할 수 있다는 의견을 어디에서나 읽을 수 있지만 올바른 해결책은 단순히 "Currency"라는 개념 일 것입니다.

다시 말해,이 규칙은 사물의 이름을 지정하는 데 어려움을 겪기 쉽고 쉬운 것은 미묘한 잘못 입니다.

실제로는 코드의 클라이언트 ( "미래의 사용자"일 수 있음)는 나중에 코드를 읽고 가능한 한 빨리 (또는 적은 노력으로) 친숙해야합니다 (클라이언트에게 제공). 그들이 얻을 것으로 예상되는 코드).

ISomething 규칙은 cruft / bad 이름을 소개합니다. 즉, 코드 작성에 사용 된 규칙과 관행이 더 이상 실제가 아니라면 크래프트는 실제 크래프트가 아닙니다. 컨벤션에 "ISomething 사용"이라고 표시되어 있으면 다른 개발자와 일치하고 더 잘 작동하기 위해 컨벤션을 사용하는 것이 가장 좋습니다.

*) 나는 이것이 "부스러기"가 정확한 개념이 아니라고 말하면서 도망 갈 수있다 :)

다른 답변에서 언급했듯이 인터페이스 이름 앞에 접두사 I는 .NET 프레임 워크의 코딩 지침의 일부입니다. 구체적인 클래스는 C # 및 VB.NET의 일반 인터페이스보다 더 자주 상호 작용하기 때문에 명명 체계에서 일류 클래스이므로 IParser인터페이스와 Parser기본 구현에 가장 단순한 이름을 가져야합니다 .

그러나 구체적인 클래스 대신 인터페이스가 선호되는 Java 및 유사한 언어의 경우, Uncle Bob은 예를 들어 구문 분석기 인터페이스 I와 같이 인터페이스를 제거하고 인터페이스의 이름이 가장 단순해야한다는 점에서 옳습니다 Parser. 그러나 ParserDefault클래스 와 같은 역할 기반 이름 대신 파서의 구현 방식 을 설명 하는 이름이 클래스에 있어야합니다 .

public interface Parser{
}

public class RegexParser implements Parser {
    // parses using regular expressions
}

public class RecursiveParser implements Parser {
    // parses using a recursive call structure
}

public class MockParser implements Parser {
    // BSes the parsing methods so you can get your tests working
}

이 방법 예를 들어,이다 Set<T>, HashSet<T>그리고 TreeSet<T>이름이 지정됩니다.

이 I = 인터페이스 규칙이 (새로운) 규칙을 위반한다는 것이 맞습니다.

옛날에는 intCounter boolFlag 등으로 모든 것을 접두어로 사용했습니다.

접두사없이 물건의 이름을 지정하고 'ConcreteParser'도 피하려면 네임 스페이스를 사용할 수 있습니다

namespace myapp.Interfaces
{
    public interface Parser {...
}


namespace myapp.Parsers
{
    public class Parser : myapp.Interfaces.Parser {...
}