대부분의 OO 언어는 인터페이스 이름 앞에 대문자 I를 붙입니다. Java가 왜 그렇게하지 않습니까? 이 협약을 따르지 않은 이유는 무엇입니까?
의미하는 바를 보여주기 위해 사용자 인터페이스와 사용자 구현을 원한다면 Java에서 두 가지 선택이 있습니다.
- 클래스 = 사용자, 인터페이스 = UserInterface
- 클래스 = 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 규칙을 사용하지 않는 몇 가지 이유가있을 수 있습니다.
-
객체 지향 접근 방식의 일부는 클라이언트가 인터페이스 또는 구현 클래스를 사용하는지 여부를 알 필요가 없다는 것입니다. 따라서 List조차도 인터페이스이고 String은 실제 클래스이므로 메소드가 둘 다 전달 될 수 있습니다. 인터페이스를 시각적으로 구별하는 것은 의미가 없습니다.
-
일반적으로 클라이언트 코드에서 인터페이스 사용을 선호합니다 (예 : List를 ArrayList보다 선호). 따라서 인터페이스를 예외로 눈에 띄게 만드는 것은 의미가 없습니다.
-
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에서 인터페이스에 대한 규칙이 거의 중요하지 않다고 생각합니다. 나는 당신이 구성하고 사람들에게 인터페이스라는 것을 보여주기 위해 무언가를 사용하는 한 원하는 명명 규칙을 선택한다고 말하고 싶습니다. 몇 년 동안 자바를 해보지 않았지만 모든 인터페이스는 자체 디렉토리에있을 것입니다. 실제로 아무런 문제가 없었습니다.
