好的在混凝土類上使用適配器模式？

我有兩個類似的具體類，由兩個不同的第三方提供（我不能修改它們）。好的在混凝土類上使用適配器模式？

是否確定，如果我使用了經典的GoF適配器模式，而是有我的適配器擴展了具體的目標類？或者這是不好的？

例子：

public class A { 
    public void doSomething() { 
     // some code 
    } 
} 

public class B { 
    public void similarDoSomethingMethod() { 
     // some code 
    } 
} 


public class BAdapter extends A { 
    private B b; 

    public BAdapter(B b) { 
     this.b = b; 
    } 
    @Overrides 
    public void doSomething() { 
     b.similarDoSomethingMethod(); 
    } 
}

來源

2014-03-18 methodex

** **是BAdapter嗎？A？如果是這樣，那麼這可能是合理的。另外，你確定通過不調用'super.doSomething（）'，你不會打破'A'的不變式（請記住，實現者當他們確實不總是使用'final'和/或文檔副作用應該有）？這看起來有點像代碼味道，但是如果沒有更多的信息就不可能提供更多的建議（例如，*爲什麼*你需要這個適配器嗎？你可以舉一個更具體的例子嗎？） –

我忘記了在原始文章中這兩個班來自兩個不同的第三方。我從第三方接收使用類A的輸入，該類需要使用類B發佈給其他第三方。因此，我收到了類A的一個實例，但我需要將它轉換爲類B的一個實例，以便我可以發送它到另一個第三方。這就是爲什麼我需要適配器。希望這是有道理的。 – methodex

我的直覺反應是否定的。一個適配器被用來提供你自己的界面。通過擴展這個類，你打開了對實際對象的調用。我認爲使用'有'關係是一個更好的主意。 – sdasdadas

適配器提供客戶端類的adaptees之間的protected variation，如果將它作爲描述：

Adapter pattern applied

這意味着，如果混凝土第三方類的演變，有一定的保障給客戶端。

如果您選擇延長A（即，使得A的接口是一個客戶端使用），若A（第三方類，你不控制）的變化，你的客戶會被打破。

另外，如果你想支持一個新的第三方擴展，你怎麼跟你的設計增加嗎？

注意，如果在適配器（以上）的「乾淨」的應用程序A的變化，只有ServiceAdapterA將斷裂。另外，如果添加新的第三方實現，則只需創建一個新適配器並使適應的服務方法起作用即可。

來源

2014-03-20 21:06:40 Fuhrmanator

我認爲擴展是一個壞主意，在這種情況下。想象一下，你正在實施圍繞以下第三方類適配器：

class Person { 

    public void walk() { ... } 

}

如果使用擴展，你可以寫：

class PersonAdapter extends Person { 

}

，你作出這樣person.walk()通話。真棒，對吧？

但是當你想隱藏散步會發生什麼？你必須棄用它，或者重寫它 - 這兩個醜陋的解決方案。

最好包裝類，然後只提供一個接口到你需要的函數。

來源

2014-03-18 21:40:12 sdasdadas

如果沒有更多來自OP的具體信息，我們所能做的最好的是猜測，它有可能導致誤導。 –

好的在混凝土類上使用適配器模式？

回答

相關問題