Java에서 인터페이스 이름 지정

대부분의 OO 언어는 인터페이스 이름 앞에 대문자 I를 붙입니다. Java가 왜 그렇게하지 않습니까? 이 협약을 따르지 않은 이유는 무엇입니까?

의미하는 바를 보여주기 위해 사용자 인터페이스와 사용자 구현을 원한다면 Java에서 두 가지 선택이 있습니다.

1. 클래스 = 사용자, 인터페이스 = UserInterface
2. 클래스 = UserImpl, 인터페이스 = 사용자

대부분의 언어로 :

클래스 = 사용자, 인터페이스 = IUser

이제는 항상 사용자 구현을 위해 가장 설명적인 이름을 선택할 수 있다고 주장 할 수 있지만 문제는 사라지지만 Java는 POJO 접근 방식을 추진하고 대부분의 IOC 컨테이너는 DynamicProxies를 광범위하게 사용합니다. 이 두 가지를 함께 사용하면 단일 POJO 구현으로 많은 인터페이스를 사용할 수 있습니다.

그래서 제 질문 은 "자바 프레임 워크가 어디로 향하고 있는가에 비추어보다 광범위한 인터페이스 명명 규칙을 따를 가치가 있습니까?"

인터페이스에 접두사를 사용하지 않는 것이 좋습니다.

• 접두사는 가독성을 떨어 뜨립니다.

• 클라이언트에서 인터페이스를 사용하는 것이 가장 좋은 프로그래밍 방법이므로 인터페이스 이름은 가능한 짧고 유쾌해야합니다. 클래스 사용을 권장하지 않기 위해 클래스를 구현하는 것이 더 어려워 야합니다.

• 추상 클래스에서 인터페이스로 변경할 때 접두사 I이있는 코딩 규칙은 클래스의 모든 항목 이름을 바꾸는 것을 의미합니다.

실제로 다음과 같은 차이점이 있습니까?

class User implements IUser

과

class UserImpl implements User

우리가 말하는 전부가 명명 규칙일까요?

개인적으로 인터페이스에 I코딩하고 싶을 때 인터페이스보다 우선하지 않으며 이름 지정 규칙 측면에서 더 중요하다고 생각 합니다 . 인터페이스 IUser를 호출하면 해당 클래스의 모든 소비자 는 인터페이스 를 알아야합니다 IUser. 클래스 UserImpl를 호출하면 클래스 와 DI 컨테이너 만 Impl파트 에 대해 알고 소비자는 자신이 작업하고 있음을 알 수 User있습니다.

그런 다음, Impl더 나은 이름이 없기 때문에 사용하도록 강요된 시간은 그 구현이 구현 에 따라 이름이 지정되기 때문에 그 사이 가 중요하지 않습니다. 예를 들어

class DbBasedAccountDAO implements AccountDAO
class InMemoryAccountDAO implements AccountDAO

Java가 일반적으로 IUser 규칙을 사용하지 않는 몇 가지 이유가있을 수 있습니다.

1. 객체 지향 접근 방식의 일부는 클라이언트가 인터페이스 또는 구현 클래스를 사용하는지 여부를 알 필요가 없다는 것입니다. 따라서 List조차도 인터페이스이고 String은 실제 클래스이므로 메소드가 둘 다 전달 될 수 있습니다. 인터페이스를 시각적으로 구별하는 것은 의미가 없습니다.

2. 일반적으로 클라이언트 코드에서 인터페이스 사용을 선호합니다 (예 : List를 ArrayList보다 선호). 따라서 인터페이스를 예외로 눈에 띄게 만드는 것은 의미가 없습니다.

3. Java 이름 지정 규칙은 헝가리어 스타일 접두어보다 실제 의미가있는 더 긴 이름을 선호합니다. 따라서 코드는 가능한 한 읽기 쉽습니다. List는 목록을 나타내고 User는 IUser가 아닌 사용자를 나타냅니다.

Spring을 포함한 많은 오픈 소스 프로젝트에서 사용되는 또 다른 규칙이 있습니다.

interface User {
}

class DefaultUser implements User {
}

class AnotherClassOfUser implements User {
}

나는 개인적으로 "I"접두어가 선택적인 규칙이라는 단순한 이유 때문에 마음에 들지 않습니다. 그래서 이것을 채택하면 IIOPConnection은 IOPConnection의 인터페이스를 의미합니까? 클래스에 "I"접두사가없는 경우 어떻게해야 인터페이스가 아닌지 알 수 있습니다. 규칙이 항상 준수되는 것은 아니기 때문에 여기에 대한 대답은 '아니오'입니다.

다른 포스터가 말했듯이 인터페이스가 유형이 아닌 기능을 정의하도록하는 것이 일반적으로 바람직합니다. 나는 "사용자"와 같은 것을 "구현"하지 않는 경향이 있으며, 이것이 여기에 설명 된 방식으로 "IUser"가 실제로 필요하지 않은 이유입니다. 나는 종종 클래스를 명사로, 인터페이스를 형용사로 본다.

class Number implements Comparable{...}  
class MyThread implements Runnable{...}
class SessionData implements Serializable{....}

때때로 형용사는 이해가되지 않지만, 일반적으로 유형이 아닌 동작, 동작, 기능, 속성 등을 모델링하기 위해 인터페이스를 사용하고 있습니다.

또한 실제로 하나의 사용자를 만들고 사용자라고 할 경우 IUser 인터페이스도 갖는 요점은 무엇입니까? 공통 인터페이스를 구현해야하는 몇 가지 다른 유형의 사용자가있는 경우 인터페이스에 "I"를 추가하면 구현 이름을 선택하는 데 무엇이 도움이됩니까?

더 현실적인 예는 일부 유형의 사용자가 특정 API에 로그인 할 수 있어야한다고 생각합니다. Login 인터페이스를 정의한 다음 SuperUser, DefaultUser, AdminUser, AdministrativeContact 등의 suclass를 가진 "User"상위 클래스를 가질 수 있습니다.이 중 일부는 필요에 따라 Login (로그인 가능?) 인터페이스를 구현하거나 구현하지 않습니다.

Bob Lee는 프레젠테이션에서 한 번 말했다.

구현이 하나 뿐인 경우 인터페이스의 요점은 무엇입니까?

따라서 인터페이스없이 하나의 구현으로 시작합니다. 나중에 여기에 인터페이스가 필요하다고 판단하므로 클래스를 인터페이스로 변환하십시오.

그러면 분명해집니다. 원래 클래스는 User라고 불 렸습니다. 인터페이스는 이제 사용자라고합니다. 어쩌면 UserProdImpl과 UserTestImpl이있을 수 있습니다. 응용 프로그램을 제대로 디자인하면 모든 클래스 (User를 인스턴스화하는 클래스 제외)는 변경되지 않으며 갑자기 인터페이스를 전달받지 않습니다.

그래서 그것은 명확 해집니다-> 인터페이스 사용자 구현 UserImpl.

C #에서는

public class AdminForumUser : UserBase, IUser

자바는 말할 것이다

public class AdminForumUser extends User implements ForumUserInterface

그 때문에 상속과 인터페이스 구현 사이에 명백한 차이가 있기 때문에 Java에서 인터페이스에 대한 규칙이 거의 중요하지 않다고 생각합니다. 나는 당신이 구성하고 사람들에게 인터페이스라는 것을 보여주기 위해 무언가를 사용하는 한 원하는 명명 규칙을 선택한다고 말하고 싶습니다. 몇 년 동안 자바를 해보지 않았지만 모든 인터페이스는 자체 디렉토리에있을 것입니다. 실제로 아무런 문제가 없었습니다.

내 경험상 "I"규칙은 특히 인터페이스 자체가 클래스의 추상적 인 개념이 아닌 경우 클래스에 대한 계약을 제공하려는 인터페이스에 적용됩니다.

예를 들어, 귀하의 경우, 유일 IUser하게 보유하려는 유일한 사용자가입니다 User. 당신은 다양한 유형의 사용자를 가질 계획이라면 - NoviceUser, ExpertUser등 - 나는 보여야하는데 User(아마도를 사용하며 인터페이스 AbstractUser가 구현하는 몇 가지 일반적인 기능, 같은 클래스 get/setName()).

나는 또한 기능을 정의하는 인터페이스를 기대 - Comparable, Iterable등 - 그런 이름이 아닌 같은 수 IComparable또는 IIterable.

좋은 OO 원칙에 따라 코드는 (실용적이고 가능한 한) 구체적인 클래스가 아닌 추상화에 의존해야합니다. 예를 들어, 일반적으로 다음과 같은 메소드를 작성하는 것이 좋습니다.

public void doSomething(Collection someStuff) {
    ...
}

이것보다:

public void doSomething(Vector someStuff) {
    ...
}

이 아이디어를 따르는 경우 "IUser", "UserInterface"또는 기타 변형이 아닌 "User"및 "BankAccount"(예 :)와 같은 인터페이스 이름을 지정하면 코드를 더 읽기 쉽게 유지할 수 있습니다.

실제 구체적인 클래스에 신경을 써야하는 코드는 콘크리트 클래스가 생성되는 장소입니다. 다른 모든 것은 인터페이스를 사용하여 작성해야합니다.

이렇게하면 "UserImpl"과 같은 "추악한"구체적인 클래스 이름이 나머지 코드에서 안전하게 숨겨져 야합니다. "nice"인터페이스 이름을 사용하면됩니다.

= v = "I"접두사는 Wicket 프레임 워크에서도 사용되는데, 여기서 빠르게 익숙해졌습니다. 일반적으로 성가신 Java 클래스 이름을 단축하는 규칙을 환영합니다. 그러나 디렉토리와 Javadoc에서 "I"로 모든 문자가 알파벳순으로 표시되어있어 번거 롭습니다.

Wicket 코딩 방법은 많은 컨트롤 / 위젯 인스턴스가 인라인 메서드 선언을 사용하는 익명 내부 클래스로 구성되어 있다는 점에서 Swing과 유사합니다. 짜증나게도 Swing은 구현 클래스에 접두사 ( "J")를 사용한다는 점에서 Swing과 180 °가 다릅니다.

"Impl"접미사는 맹렬한 약어이며 국제화가 잘되지 않습니다. 만약 우리가 최소한 "Imp"로 간다면 그것은 더 짧을 것입니다. "Impl"은 IOC, 특히 Spring에 사용되므로 지금은이 유형에 붙어 있습니다. 그러나 하나의 코드베이스의 세 가지 다른 부분에서 세 가지 다른 규칙에 따라 약간의 정신 분열을 얻습니다.

이것은 실제 의미에서 더 광범위한 명명 규칙입니까? 나는 C ++ 측면에 더 많이 있지만 실제로 Java와 자손에 대해서는 아닙니다. I 규칙을 사용하는 언어 커뮤니티는 몇 명입니까?

언어 독립적 상점 표준 명명 규칙이있는 경우이를 사용하십시오. 그렇지 않은 경우 언어 명명 규칙을 따르십시오.