기능 추가 : 서브 클래스 대 데코레이터

Question

현재 프리젠 테이션 레이어에 Oracle ADF Faces JSF 구현을 사용하는 레거시 시스템에서 작업하고 있습니다. 시스템은 규칙 엔진을 사용하여 사용자와의 상호 작용이나 입력 된 값에 따라 특정 양식 요소가 필수, 사용 불가능 또는 강조 표시되도록합니다.

현재 응용 프로그램이 "작동 중"입니다. 규칙 엔진과 프론트 엔드 업데이트를 처리하는 현재의 구현은 매우 우아하지 않고의 큰 집합으로 구성 유사 if 문 :

if(screenObj instanceof CoreInputText) { 
    ((CoreInputText) screenObj).setDisabled(true); 
} 

우리는 또한 우리 자신의 객체가 있으므로 혼합이 믹스를 복잡하게

((CommonAncestor) screenObj).setDisabled(true); 

문제는이 깨끗하고 명확하게하기 위해 코드의이 부분을 재 작업 가치가있을 것입니다 여부입니다 : 따라서 같은 일을하고 우리의 옵션을 제거 공통 조상을 공유하지 않습니다 전체로 설정합니다. 대부분의 화면 요소가 ADF Faces 요소이기 때문에 추가 방법을 추가하기 위해 조상을 변경할 수 없습니다.

코드 변경의 목표는 두 가지입니다. 이전 코드를 정리하고 새 요소 또는 컨트롤을 추가해도 큰 코드 변경이 발생하지 않도록 코드베이스를 개선하십시오 (특히 존재하는 if 문 수많은 장소에서).

그래서 우리가 찾고있는 것을 달성하기위한 더 나은 선택이 될이 변화를 계속한다면? 모든 요소를 ​​서브 클래 싱 (기존의 다른 컨트롤을 사용할 때마다 새 클래스가 필요함)하거나 데코레이터 패턴을 구현합니까? 데코레이터에 대한 유일한 관심사는 여전히 각 추가 요소에 대한 코드 변경이 필요하다는 것입니다. 이 두 블록을 포함하는 여러 메소드가 업데이트 할 필요가 없으므로 두 옵션 모두 코드 변경을 줄이는 것처럼 보입니다.

서브 클래 싱 및 데코레이터 이외의 상황을 처리하는 메소드에 대한 모든 입력을 환영합니다!

Answer 1

공통 조상이 없지만 공통 방법이 있는지 지정하지 않습니다. 만약 그렇다면, 아마도 단지 하나의 공통된 타입을 갖기 위해 메소드를 호출하는 Proxy를 사용하여 런타임시 인터페이스에 넣을 수 있습니다. 이는 일종의 데코레이터입니다. 리플렉션을 사용하기 때문에 너무 느릴 수는 있지만 (올바른 것은 아니지만) 올바른 메소드 시그니처를 구현해야하는 새로운 객체의 장점이 있습니다. (또는 새 객체가 인터페이스를 만들고 이전 객체에 대한 프록시를 예약하고 객체가 필요로하는지 확인하는 팩토리 메소드에 조건부로 프록시를 작성하십시오.

또한 이것이 진정한 세터라면 Apache의 BeanUtils를 사용하고 disabled라는 속성으로 설정할 수 있습니다.

EDIT : 동일한 메소드가 없다는 것을 감안할 때 새로운 객체를 추가 할 때마다 새로운 객체가 추가 될 때마다 코드를 추가해야합니다. . 즉, 만약 당신이 반사 경로를 내려가는 것이 편안하다면, 메소드에 대한 클래스의 맵을 생성 할 수 있습니다 (메소드가 모두 부울을 취하면 - 그리고 필요하다면 주위를 강요 할 수도 있습니다). 그리고 객체를 룩업 할 수 있습니다 지도에서. 그렇게하면 새 오브젝트를 도입 할 때 맵에 항목을 추가하기 만하면됩니다.

그러나, 내 취향은 그것을 피하는 것입니다. 반사가 너무 먼 것처럼 보입니다. 메서드 이름을 리팩터링하기가 매우 어렵게 만들고, IDE가 메서드 이름을 리팩토링에 사용한다는 것을 알아내는 것은 불가능합니다.다른 고려 사항을 무시하고 구성이 상속에 우선해야하고, 발생하는 상황에 대한 명확한 코드 경로를 만들어 장기적으로 유지 관리를 개선하기 때문에 데코레이터가 첫 번째 홍당무에서 올바른 선택이라고 생각합니다.