고정 인터페이스

Constant interface

Java 프로그래밍 언어에서 상수 인터페이스 패턴은 상수를 정의하기 위한 인터페이스의 사용만을 기술하며, 이러한 상수에 대한 편리한 구문 액세스를 달성하기 위해 클래스가 해당 인터페이스를 구현하도록 합니다.단, 상수는 구현 세부사항일 뿐이고 클래스에 의해 구현된 인터페이스는 내보낸 API의 일부이기 때문에 이 방법은 구현 세부사항을 API에 넣는 것과 같으며, 이는 Java 디자이너 Joshua Bloch에 [1]의해 부적절하다고 간주되었습니다.일반적으로, 시스템 상수를 동작으로부터 독립된 클래스로 수집하는 것은 종종 낮은 응집성의 신호이기 때문에 좋지 않은 객체 지향 설계를 만들 수 있다.이러한 이유로, 고정 인터페이스는 안티 패턴으로 간주될 수 있습니다.

이 패턴의 사용에는 몇 가지 다른 [original research?]단점이 있습니다.

  1. 클래스 네임스페이스를 사용할 수 없는 읽기 전용 변수로 오염시킵니다.
  2. 일정한 인터페이스를 구현하는 컴파일 시간 전술 유틸리티와는 달리, 부수적인 런타임 아티팩트는 실질적인 목적이 거의 없다(마커 인터페이스도 방법이 없지만 런타임에 유용하다.
  3. 향후 릴리스에서 바이너리코드 호환성이 필요한 경우, 기존의 의미의 인터페이스로 사용되지 않은 경우에도 상시 인터페이스는 인터페이스로 영원히 유지되어야 합니다(클래스로 변환할 수 없습니다).
  4. 상수의 출처를 해결하는 IDE가 없는 경우, 그 IDE를 포함한 클래스 또는 인터페이스까지 추적하는 것은 시간이 걸릴 수 있습니다.
  5. 인터페이스의 인스턴스는 구문적으로 인터페이스 이름 자체보다 유용하지 않습니다(메서드가 없기 때문에).
  6. 개발자가 클래스에 상수를 추가할 때 구현된 인터페이스를 체크하거나 체크하지만 추가된 상수의 이름으로 오타가 발생하지 않는 한 상수의 값은 사일런트하게 변경될 수 있습니다.아래의 예 2를 참조해 주세요.

Java 라이브러리는 일정한 인터페이스 패턴 자체를 사용하고 [2]있기 때문에 상황에 따라서는 이것이 합리적인 선택일 수 있습니다.

예 1

일반의 인터페이스 상수 {   이중으로 하다 PI = 3.14159;  이중으로 하다 플랑크_상수 = 6.62606896e-34; }  일반의 학급 계산 용구 상수 {   일반의 이중으로 하다 get Reduced Planck Constant() {   돌아가다 플랑크_상수 / (2 * PI);  } }

예 2

일반의 인터페이스 상수 {   일반의 정적인 최종 인트 일정한 = 1; }  일반의 학급 클래스 1 용구 상수 {   일반의 정적인 최종 인트 일정한 = 2; // *   일반의 정적인 무효 주된(스트링 args[]) 던지다 예외. {   시스템..나가..인쇄(일정한);  } }

아스타리스크 마크가 붙은 행을 추가하기 전에 Class1을 실행하면1 이 인쇄됩니다.행을 추가하면 Class1은 2를 인쇄합니다.두 버전 모두 경고나 오류 없이 컴파일됩니다.

대체 수단

안티 패턴의 함정의 대부분은 고정 인터페이스를 스태틱애트리뷰트를 가진 클래스로 변환함으로써 회피할 수 있습니다.

일반의 최종 학급 상수 {   사적인 상수() {   // 인스턴스화 제한  }   일반의 정적인 최종 이중으로 하다 PI = 3.14159;  일반의 정적인 최종 이중으로 하다 플랑크_상수 = 6.62606896e-34; }

Java 5부터는 정적[3] 가져오기를 사용하여 상수 한정자 없이 상수를 사용할 수 있습니다.

Import 스태틱 상수.플랑크_상수; Import 스태틱 상수.PI;  일반의 학급 계산 {   일반의 이중으로 하다 get Reduced Planck Constant() {   돌아가다 플랑크_상수 / (2 * PI);  } }

정적 상수 가져오기를 사용하여 상수를 일괄 가져올 수도 있습니다.* 스테이트먼트이는 인터페이스를 사용하는 것과 동일한 목표를 달성하므로 한정자 없이 상수를 참조할 수 있습니다.

상기의 문제는, 다양한 정도로 해결되고 있습니다.

  1. 스태틱 멤버를 구체적으로 Import할 수 있기 때문에 클래스 네임스페이스를 상수 인터페이스의 모든 멤버로 오염시킬 필요는 없습니다.
  2. 런타임과 컴파일 타임의 시멘틱스는, 고정 인터페이스 대신에 스태틱 Import를 사용하는 경우에 보다 밀접하게 일치합니다.
  3. 컴파일된 코드에는 이진 호환성 제약 조건이 하나 적습니다("class calculations implements constants").
  4. 정적 가져오기는 클래스 계층 전체가 아닌 현재 파일에만 적용되므로 각 정적 구성원이 선언된 위치를 쉽게 검색할 수 있습니다.
  5. 일정한 인터페이스 타입의 변수를 선언할 필요가 적어지고 구체적인 인스턴스가 존재하지 않는 것이 잠재적으로 명확해집니다.

단, 이러한 변경은 상수 클래스의 응집력을 개선하는 데 아무런 도움이 되지 않으며 상수 값의 우발적인 사일런트 수정을 방지하지 않으므로 정적 가져오기를 만병통치약으로 간주해서는 안 됩니다.

레퍼런스

  1. ^ Bloch, Joshua, Effective Java, 제2판, 페이지 98
  2. ^ "스윙 상수"
  3. ^ "스태틱 Import"