我剛剛瞭解到Bridge模式及其意圖：將抽象與其實現分離，以使兩者可以獨立變化。AbstractFactory與橋接模式
但爲什麼不能只是AbstractFactory做同樣的事情？
我知道一個AbstractFactory可以創建一個特定的橋，但我的問題涉及到的AbstractFactory代替Bridge使用去耦抽象和實現。
請您解釋一下AbstractFactory和Bridge模式的真正區別嗎？
首先，我讀過的橋樑模式更多的是當班級和班級經常變化。類本身可以被看作是抽象的實現和類的行爲。
另一方面，抽象工廠提供了一個用於創建相關或依賴對象組的接口，而不指定它們的具體類;他們的實施擔憂。
所以我想總結一下，你在比較蘋果和橙子，也許這就是混淆來自何處。他們是爲了解決不同的問題。
對我來說操作意味着java中的方法，所以操作是由抽象定義或聲明的，但是在類中實現。因此，抽象只是聲明操作可以做到的行爲，但實際的實現是在類中完成的。此外，抽象工廠也是正確的。
我想橋樑的定義部分是它可能有一組抽象與一個抽象不同。
設計模式使用抽象一詞來指代一個依賴抽象操作集合的類，其中抽象操作集合的幾個實現是可能的。
更多信息請參見以下鏈接：
是。他們是相似的。 AF用於創建對象的家族。 Bridge更多的是關於行爲，還允許算法和平臺之間的鬆散耦合。
例如：假設我們使用Ping和Traceroute開發網絡診斷程序，不同平臺上的命令是不同的。抽象工廠可用於爲任何平臺獲取ping或traceroute的實例。 它並沒有在那裏結束。 Bridge允許我們使用AF返回的ping和trace命令開發更高級的算法。根據平臺，可以使用ping和traceroute的不同序列的算法可以使用橋接模式從平臺特定的實現細節中抽象出來。
有一些差異，我們不能比較兩者。
抽象工廠是造物設計模式，這與創建對象的交易。 橋是結構設計圖案，其與類結構和組合物，涉及。
在橋，抽象和實現將獨立變化。但在抽象工廠中，如果更改抽象（接口），則必須更改客戶端。
abstract_factory模式使用案例：
清單：
bridge模式：
使用它的時候：
相關SE問題：
Does the Bridge Pattern decouples an abstraction from implementation?
What is the basic difference between the Factory and Abstract Factory Patterns?
看一看這個journaldev文章和sourcemaking文章深入各種設計模式的理解。
感謝您的解釋。告訴我，我們是對的：在Bridge中，所有原始操作都應該由實現者來實現，而不是抽象本身。另一方面，對於AbstractFactory，它的意圖只是創建對象（例如包含在Bridge模式的抽象方面的對象），但是這種模式從來不期望所有的基本操作都必須在抽象方面實現。因此無法使用對於所有基本操作，始終委派類似objectCreatedByFactory.doSomething（） – Mik378