最終方法的Java類裝飾器

Question

我有一個（Java）類，WindowItem，有一個問題：其中一個方法不是線程安全的。我無法修復WindowItem，因爲它是外部框架的一部分。所以我想我爲它實現了一個裝飾器，它在所討論的方法上有一個「同步」關鍵字。

裝飾器擴展WindowItem並且還包含WindowItem。在Decorator模式之後，我在Decorator中創建了調用它所包含的WindowItem的方法。

但是，WindowItem有幾個最終方法，我不能在裝飾器中重寫。這打破了裝飾者的透明度。讓我們更加明確：

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（項目） - 和線程安全問題就消失了。但是，如果我的代碼在WindowItemDecorator上調用getwindowCount（），它將始終爲零：它在超類上執行getWindowCount（），而不是「item」成員。

所以我會說WindowItem的設計（它具有公共final方法的事實）使得不可能爲這個類創建一個裝飾器。

這是正確的，還是我錯過了什麼？

在這種情況下，我可能會保留裝飾器中窗口列表的副本，並保持同步，然後getWindowCount（）的結果將是正確的。但在這種情況下，我更喜歡叉和修補框架...

Answer 1

你的問題的答案是肯定的，你不能重寫最終方法，這意味着它不可能爲這個類創建一個裝飾器。

如果您可以重寫出現問題的方法，並通過同步方法來解決問題，則可以將其留在那個位置。也就是說，只需使用你的子類，而不要使用裝飾器模式。

Answer 2

也許你可以使用Delegation Pattern，如果WindowItem類實現了一個定義你所關心的所有方法的接口，這將很好地工作。或者，如果它不打破太多的現有代碼來引用這個委託類而不是WindowItem。

Answer 3

一位同事有一個想法，我認爲可以解決問題。我可以通過查看修改List窗口的所有方法來保持超類的狀態和「item」成員的狀態同步。有幾個：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以更好地支持線程安全。

事實上，如果該類不是線程安全的，幾個​​關鍵字不太可能真正解決問題。究竟是什麼人的意思是「線程安全」永遠是相對的;-)

（順便說一句，WindowItem絕對是不線程安全的，因爲它是用List而是明確使用的「螺紋準備」變種Correct way to synchronize ArrayList in java - 也有不保證以線程安全的方式訪問List）。