최종 메소드가있는 Java 용 Decorator

Question

WindowItem 클래스에 Java 클래스가 있습니다.이 메소드 중 하나는 스레드로부터 안전하지 않습니다. WindowItem은 외부 프레임 워크의 일부이기 때문에 수정할 수 없습니다. 그래서 나는 그것에 대한 Decorator를 구현하는 것을 알았다. 그것은 문제의 메서드에 "동기화 된"키워드를 가지고있다.

Decorator는 WindowItem을 확장하며 WindowItem도 포함합니다. 데코레이터 패턴 다음에는 데코레이터에 포함 된 WindowItem을 호출하는 데코레이터에 메서드를 만듭니다.

그러나 WindowItem에는 데코레이터에서 재정의 할 수없는 몇 가지 최종 방법이 있습니다. 이로 인해 Decorator의 투명성이 손상됩니다. 의이 명시 만들어 보자 : 새로운 WindowItemDecorator (아이템) -와 스레드 안전 문제가 사라 : 내 자신의 코드에서

public class WindowItem { 
    private List<WindowItem> windows; 

    public Properties getMethodWithProblem() { 
     ... 
    } 

    public final int getwindowCount() { 
     return windows.size(); 
    } 
} 

public class WindowItemDecorator extends WindowItem { 
    private WindowItem item; 

    public WindowItemDecorator(WindowItem item) { 
     this.item = item; 
    } 

    # Here I solve the problem by adding the synchronized keyword: 
    public synchronized Properties getgetMethodWithProblem() { 
     return super.getMethodWithProblem(); 
    } 

    # Here I should override getWindowCount() but I can't because it's final 
} 

를, 내가 어딘가 WindowItem을 통과해야 할 때마다, 내가 먼저 장식에 싸서. 그러나 내 코드가 WindowItemDecorator에서 getwindowCount()를 호출하면 항상 0이됩니다. "item"멤버 대신 슈퍼 클래스에서 getWindowCount()를 실행합니다.

그래서 나는이 클래스에 대한 장식자를 만드는 것이 불가능하게 만드는 WindowItem (public final 메서드가 있다는 사실)의 디자인을 말합니다.

맞습니까? 아니면 뭔가 빠졌습니까?

이 경우 데코레이터에 창의 목록 복사본을 유지하고 동기화 상태로 유지 한 다음 getWindowCount() 결과가 정확할 수 있습니다. 그러나이 경우 프레임 워크를 포크하고 패치하는 것을 선호합니다 ...

Answer 1

질문에 대한 답은 예입니다. 최종 메서드를 재정 의하여 할 수 없으므로이 클래스의 데코레이터를 만들 수 없습니다.

문제가있는 메서드를 재정의하고 메서드를 동기화하여 문제를 해결할 수 있으면 그냥 그대로 두어도됩니다. 즉, 하위 클래스를 사용하고 데코레이터 패턴을 사용하지 말라.

Answer 2

아마도 Delegation Pattern을 사용할 수 있습니다. WindowItem 클래스가 관심있는 모든 메서드를 정의하는 인터페이스를 구현하면 제대로 작동합니다. 또는 WindowItem이 아닌 위임 된 클래스를 참조하기 위해 기존 코드를 너무 많이 손상시키지 않는 경우

Answer 3

동료가 문제를 해결할 수 있다고 생각했습니다. 목록 창을 수정하는 모든 메소드를 살펴봄으로써 "항목"멤버의 상태와 수퍼 클래스의 상태를 동기화 할 수 있습니다. 몇 가지가 있습니다 : addWindow, removeWindow. 대신 호출하는 그냥 "item.addWindow는 (...)"데코레이터에, 나뿐만 아니라 슈퍼 클래스에 addWindow 전화 :

보통 장식 :

public void addWindow(WindowItem newItem) { 
    item.addWindow(newItem); 
} 

이 경우 내가 할 :

public void addWindow(WindowItem newItem) { 
    super.addWindow(newItem); 
    item.addWindow(newItem); 
} 

상태를 동기화 상태로 유지하고 최종 메소드의 반환 값이 정확합니다.

이것은 장식 된 클래스의 내부 구조에 따라 작동하거나 작동하지 않을 수있는 솔루션입니다.

Answer 4

이런 식으로 문제를 생각하지 않으시겠습니까? WindowItem의 스레드 안전성을 가정하지 않고 코드에서 스레딩 문제를 처리하지 않는 것이 좋습니다.

// I personally prefer ReadWriteLocks, but this sounds like it will do... 
synchronized (windowItem) { 
    windowItem.getMethodWithProblem(); 
} 

그런 다음 스레드 유지 관리를 위해 RFE를 패키지 관리자와 함께 제출하십시오.

실제로 클래스가 스레드 안전성을 갖도록 설계되지 않은 경우 일부 synchronized 키워드가 실제로 문제를 해결할 가능성은 거의 없습니다. 더도있다 - 어떤 누군가가 "스레드 안전"의미가 명시 적으로를 사용하는 대신 List을 사용하여 변형 Correct way to synchronize ArrayList in java "를 준비 스레드"있는 그대로 ;-)

이 (덧붙여, WindowItem 확실히 스레드로부터 안전하지 항상 상대적이다 List이 스레드 안전 방식으로 액세스되고 있음을 보장합니다.