인터페이스 이름 지정 : 접두사 'Can-'vs 접미사 '-Able'

인터페이스의 접미사로 '-able'을 사용하는 것이 일반적입니다.

직렬화 가능 인쇄 가능 열거 가능 음주 가능 회전 가능

나는 'Can-'가 더 설명하기 쉽기 때문에 더 좋을 것이라고 생각했습니다. 그렇습니다. 더 장황하고 인터페이스 이름에 노이즈를 추가합니다. 특히 수동 동사를 사용할 수 있습니다.

예를 들어 1 은 사격 가능함은 물체가 사격 할 수 있거나 (총이이를 구현할 수 있음) 또는 사격 할 수 있음을 의미합니다 (타겟 보드가이를 구현할 수 있음). 'Can-'접두어를 사용하면 전자는 "CanShoot"이고 후자는 "CanBeShotAt"또는 "CanShootAt"입니다.

예 2 문서 'CanBePrinted'및 프린터 'CanPrint'

아니면 '-Able'을 고수 하고 문서가 맥락을 제공하도록해야합니까?

모든 의견.

아마도 당신은 Is-able을 원하십니까?

.Net의 일부 예 :

NetworkStream.Readable
NetworkStream.Writable
Stream.CanRead
Stream.CanWrite
Type.IsSerializable

균일 한 표준이없는 것 같습니다. 잘 읽는 것과 함께 가십시오.

if (document.IsPrintable && printer.CanPrint) { printer.Print(document) }

편집 : 지적한 바와 같이, 질문은 속성이 아닌 인터페이스에 관한 것이 었습니다.

이 경우 Can-라는 인터페이스를 찾을 수 없습니다. 인터페이스는 항상 -able을 사용하는 경향이 있습니다. 이 용어에 동의합니다. 방법은 파라미터 A와 요청할 수 ISerializable object또는 IPrintable document. a ICanBeSerialized object또는 a를 묻는 ICanBePrinted document것은 읽기가 매우 어색합니다.

다른 한편으로는 프린터에서 간단히 인터페이스를 호출하는 것이 좋습니다 IPrinter. 귀하의 방법은을 요구할 것입니다 IPrinter device.

아래의 메소드 서명을 크게 읽으십시오. (개인적으로는 "I"접두사가 자동으로 간주됩니다.) 잘 읽습니까? 소리가나요?

void PrintDocument(IPrinter device, IPrintable document)
{
    device.Print(document)
}

문법적으로 말하면, "canFoobar"는 술어이고 "Foobarable"은 형용사 또는 명사 (일반적으로 API의 문맥에서 명사)입니다.

또한 미묘한 차이점에 주목하십시오. -able은 그것이 적용되는 명사에 수동적 역할을 의미합니다. 활동적인 역할을 의미 할 수 있습니다. 즉, 무언가 canFoobar 인 경우 다른 것을 foobar 할 수 있습니다. 또는 다른 각도에서 : A가 B를 foobar 할 수 있으면 A.canFoobar()and B is Foobarable.

OOP 표현성 측면에서, 나는 술어를 메소드 또는 특성과 연관시키는 반면 명사는 클래스 또는 인터페이스입니다. 그래서:

instance.canFoobar();

class Something implements Foobarable { ... }

개인적으로 나는 가능 버전을 고수 할 것입니다. 내 이유는 다음과 같습니다. 대부분의 그래픽 편집기는 입력 한 내용에 따라 식별자를 제안합니다. 그들 중 일부는 식별자 내에서도 검색하기에 '스마트'하지만 일부는 여전히 식별자의 검색 시작을 제공합니다.

입력 속도를 높이려면 가능한 한 적은 키 입력으로 제안 된 식별자 목록을 줄이려고합니다. 시작과 같은 식별자가 많을수록 (예 : 'ICan-') 더 많은 문자를 입력해야합니다.

이것이 귀하의 경우에 문제가 아니라고 생각하면 훌륭합니다. 다른 기준을 사용하여 명명 규칙을 선택하는 것이 좋습니다. 경우에 따라 (예 : 팀) 가능한 한 적은 키 입력 후 구별하는 식별자를 선호합니다.

그 외에도 프로젝트에서 작업하는 사람들에게 코드를 가장 잘 이해할 수 있도록 명명 규칙을 사용하는 것이 좋습니다. 팀 내에서 대화하십시오. 옳고 그름은 없습니다. 작동하는 규칙과 덜 작동하는 규칙.

좋은 리팩토링 도구를 사용하면 원하는 이름으로 자주 이름을 바꿀 수 있습니다. 따라서 다양한 접근 방식을 쉽게 실험 할 수 있습니다.

접두사와 접미사는 분명히 다른 유형의 행동이나 오히려 다른 행동의 방향 에 대한 명백한 선택입니다 .

그러나 여러 가지 이유로 현재 사용 및 환경 설정이 일치하지 않을 수 있습니다.

액션은 수행 에 의해 객체 :
CanShoot는 -> 그것은 촬영 (에서) 뭔가
CanFly는 -> 그것은 날아
CanChange을 -> 그것은 변경

작업 수행 에 객체 :
읽을 수를 -> 당신은 그것을 읽을 수있는
기록 가능 -> 당신은 그것을 (를) 쓸 수 있습니다
인쇄 -> 당신은 그것을 인쇄 할 수 있습니다

규칙이 아니거나 반드시 논리적 일 필요는 없지만, 규칙을 채택하고 변수 이름 지정에 일관성을 유지하는 데 도움이됩니다.

기능과 권한을 구별하고 싶을 것 같습니다. 동안 Serializable과 CanSerialize뭔가 직렬화 될 수있는 것을 의미, 또한 권한 문제 (혹은 디스크 공간 부족) 당신이 고려해야 할 수도있다 MaySerialize. 에서 일을 떠나 ~able제거합니다 구별 할 필요가 can와 may.

인터페이스를 서브 클래 싱 / 구현할 때 경험상 "B는 A"(B는 A를 구현)라고 말할 수 있어야합니다. 다음과 같이 말하는 것이 옳지 않습니다.

A Document는CanBePrinted

그러나 다음과 같이 말하는 것이 맞습니다 (또는 적어도 더 좋습니다).

A Document는Printable

문법과 관습에 따른 Xable은 인터페이스 이름에 더 좋고 IsX, CanX, DoesX는 속성 이름에 더 좋습니다.

MSDN에서 :

"부울 속성의 이름을 긍정 문구로 지정하십시오 (CantSeek 대신 CanSeek). 선택적으로 부울 속성 앞에 Is, Can 또는 Has를 붙일 수 있지만 값을 추가하는 위치에만 사용할 수 있습니다." http://msdn.microsoft.com/en-us/library/ms229012.aspx

제 생각에 "-able"변형은 훨씬 더 많은 낙타 혹을 부과하는 "CanDoSomething"제안보다 훨씬 더 읽기 쉽습니다.

스칼라에서는 *Able인터페이스에 Can*사용 되지만 유형 클래스 패턴에 사용됩니다. 본질적으로 특정 메소드를 호출 할 수 있으려면 특정 유형의 내재 된 값이 범위 내에 있어야합니다. 이 유형의 이름 앞에는 접두사가 붙습니다 Can.