인터페이스가 아닌 추상 클래스를 사용하여 매개 변수화하는 경우가 있습니까?

Question

저는 현재 상태 기반의 구성 요소 기반 API를 개발 중입니다. 최상위 레벨 구성 요소는 각각 약 12 ​​개의 인터페이스를 구현합니다.

따라서 재고 최상위 구성 요소는 여러 구현을 포함하고 여러 mixin 인터페이스를 구현하는 추상 구현 스택의 꼭대기에 위치합니다.

지금까지 너무 좋았습니다 (희망).

문제는 기본 기능이 구현하기가 매우 복잡하기 때문에 (기본 레이어 5 개 레이어에서 1,000 개의 줄) 구성 요소 작성자가 인터페이스 자체를 구현하는 것이 아니라 기본 클래스를 확장하는 것입니다. 모든 보일러 플레이트 코드는 이미 작성되어 있습니다).

따라서 API가 구성 요소 작성자가 확장하려는 Abstract 구현에 대한 참조가 아닌 인터페이스를 허용하는 경우 구현자가 다른 영역의 코드에서 필수 및 가정 한 유효성 검사를 수행하지 않을 위험이 있습니다. .

따라서 내 질문은 API가 구현하는 인터페이스에 대한 참조가 아닌 추상 구현 참조를 사용하여 API 메소드를 paramerise하는 것이 유효 할 때가 있습니까?

이 기술을 사용하는 잘 디자인 된 API의 예가 있습니까? 아니면 나 자신을 나쁜 관행으로 말하려고합니까?

Answer 1

지금까지 매우 좋았다 (희망).

아닙니다. 12 개의 인터페이스를 구현하는 것은 좋은 징조가 아닙니다. 하지만 코드를 모르기 때문에 구조 조정 방법을 말할 수 없거나 가능할 수 있습니다.

따라서 내 질문은 구현되는 인터페이스에 대한 참조가 아닌 추상 구현 참조를 사용하여 API 메소드를 paramerise하는 것이 유효 할 때가 있습니까?

희소하게, 그렇습니다. 예 : (Java) :

• JSF : javax.faces.context.FacesContext은 추상적이지만 매개 변수로 전달됩니다.
• EL : javax.el.ELContext- 도토.
• AWT : java.awt.Image - 동토.

하지만 어쨌든, 아니오라고 말하고 싶습니다. 개발자를 구현하도록 제약하는 것은 바람직하지 않습니다. 언급 된 유효성 검사를 수행해서는 안되는 모의 (mock)를 제공하거나 동적 프록시를 사용할 수도 있습니다.

마지막으로, 인터페이스를 재구성 할 수 없다고 확신하는 경우, 가능한 한 추상적 인 클래스 매개 변수를 사용하지 않을 수 있습니다.