在物件導向程式設計中建立乙個物件通常通過new關鍵字來建立,但是往往在一些業務場景下,個別物件是乙個比較複雜的bean。此時「建立物件」不光是new了,還需要一些額外的操作,比如填充資料,附屬物件的準備等等。如果我們想要得到這樣的乙個物件,直接簡單粗暴的在需要的時候,建立、準備資料。。。做這些操作的話,那我麼你的**將臃腫不堪,到處充斥著業務邏輯,業務需求變化時,就gg了。我們身為高貴的軟體工程師,必須保持著**潔癖,如何提公升**質量呢?那就運用到今天的主角:工廠模式。
工廠模式是代替new來建立物件的一種設計模式,作用是降低**耦合度,提公升程式的易擴充套件性。
簡單工廠模式
工廠方法模式
抽象工廠模式
三種模式都是工廠模式,他們都具有工廠模式的優點,抽象程度從上到下越來越高,分別都有不同的適用場景,接下來逐一介紹。
簡單工廠的角色分為3個
舉例:
比如我正在「吃雞」,跳傘剛落地,急需一把槍防身.
有如下類
public abstract class gun
public void shoot()
}public class m416 extends gun
}public class ak47 extends gun
}
沒有使用工廠模式時**是這樣的
gun gun = new ak47();
或gun gun = new m416();
使用了工廠模式時
public class ******factory
}public enum guntype
}
客戶端呼叫:
public class ******factoryclient
}
這樣**就清晰多了,這就好比沒用工廠模式時自己要冒險去找槍,需要知道業務的細節。使用了工廠模式,只需要大喊一聲我要m4,就有快遞員把槍送到你面前,而不需要知道獲得槍的過程。
這就是簡單工程模式,簡單工程模式確實將**解耦了,但是如果我們想要awm呢?需要增加一種列舉,然後多加乙個case語句,這是不符合設計模式的開閉原則(對擴充套件開放,對修改關閉)。接下來我們介紹下一種,工廠方法模式。
工廠方法的角色分為4個
舉例:
之前簡單工廠中使用了switch case來判斷到底要返回哪個例項,此時我們可以將switch case給代替。
我們定義乙個抽象的槍工廠
public inte***ce gunfactory
然後分別定義具體的ak47工廠和m416工廠
public class ak47factory implements gunfactory
}public class m416factory implements gunfactory
}
客戶端呼叫:
public class factoryclient
}
當我們需要獲得awm時,則只需要新增乙個awm類和乙個awmfactory讓其實現gunfactory即可,這樣避免了寫switch case,符合了開閉原則。
此時有的小夥伴可能會問,最初不適用工廠方法時是用new ak47()來獲得槍,現在使用new ak47factory()不是和之前一樣嗎?說明下,這是我假設的ak47可能僅僅只是需要new以下,但在我們實際的場景中,有些bean的建立是及其複雜,他可能是其他開發人員負責的邏輯,你去對接時根本不需要了解其中的細節,只需要獲得僅此而已。工廠模式就是封裝了構建產品的細節,客戶端根據想要的產品,選擇對應的工廠就可獲得相應的產品。
我們現在得到了槍,但是還沒有子彈和配件,此時我們想要直接得到一把滿配的槍。
但是子彈的型別有多種,配件的型別也有多種,此時我們又想到了為子彈和配件建立工廠,但是我們獲得一把槍滿配的槍並不需要知道怎麼獲得子彈和配件,所以我們的槍工廠就要直接包含子彈工廠和配件工廠,因此我們的抽象工廠模式呼之欲出。
抽象工廠的角色分為4個
舉例:
首先我們建立子彈的類
public abstract class bullet
public string getname()
public bullet setname(string name)
}public class ak47bullet extends bullet
}public class m416bullet extends bullet
}
接著是子彈工廠
public inte***ce bulletfactory
public class ak47bulletfactory implements bulletfactory
}public class m416bulletfactory implements bulletfactory
}
配件的**與其相同只不過是名字換乙個,此時是不是發現我們的子彈工廠和我們之前實現的槍工廠其實是一模一樣的。我們都使用了工廠方法模式,但是我們最終想要獲得是完整的滿配的槍,即槍中包含了子彈和配件。所以抽象工廠模式就將一系列具有相同主題的工廠封裝在一起。
因此抽象工廠解決的範疇是產品族等級(完整的槍),工廠方法模式解決的範疇是產品等級(子彈、配件)。
槍工廠
public class ak47factory implements gunfactory
}public class ak47 extends gun
}public abstract class gun
public void shoot()
public bullet getbullet()
public gun setbullet(bullet bullet)
}
客戶端呼叫
public class factoryclient
}
三種工廠方法都有各自的優缺點,也有各自的試用場景
簡單工廠方法:工廠類含有必要的判斷邏輯,可以決定在什麼時候建立哪乙個產品類的例項,客戶端可以免除直接建立產品物件的責任,而僅僅"消費"產品。耦合度低。明確區分了各自的職責和權力,有利於整個軟體體系結構的優化。
工廠方法模式:工廠方法模式是為了克服簡單工廠模式的缺點。簡單工廠模式的工廠類隨著產品類的增加需要增加很多方法(或**),而工廠方法模式每個具體工廠類只完成單一任務,**簡潔。工廠方法模式完全滿足ocp,即它有非常良好的擴充套件性。
抽象工廠模式:抽象工廠模式主要在於應對「新系列」的需求變化。分離了具體的類,乙個抽象工廠建立了乙個完整的產品系列,所以整個產品系列會立刻改變。它有利於產品的一致性。是對多個構成產品的「零件」工廠的封裝,使乙個切換產品主題變得極為容易。
其實在我們日常做需求時,**的架構可能是一步一步演化的,最開始接到需求可能就是連三種產品,這是我們可能就設計成簡單工廠模式。之後產品增加多了,而且其他開發人員可能也要處理這邊的邏輯,則原先的switch case很有可能就會成為bug的伏筆。此時架構便可以公升級為工廠方法模式。再後來原來的產品變得龐大且複雜,需要將產品設計成多個零件構成,此時架構又可以公升級成抽象工廠模式,將耦合度進一步降低,之後其他的開發者想要新增產品,一看結構清晰明了,便可以高質量的完成工作,早早下班回家。
設計模式幫助我們提公升**質量,每種設計模式都有其適合的場景,切勿過度設計,讓技術推動業務,不定時重構**,不斷構造更好的自己。
歡迎各路大神不吝賜教。
設計模式 工廠模式 抽象工廠模式
建立物件時不會對客戶暴露建立邏輯,並且通過使用乙個共同的介面來指向建立的物件。sept1 建立乙個公共介面,將要對外開放的方法在這裡定義。sept2 建立實現介面的類,用即實現對外開放的類的方法 sept3 建立工廠,提供乙個get方法,這個方法提供返回實現類的物件 建立選擇 sept4 使用,建立...
設計模式 工廠設計模式
用於建立物件的介面,交給子類去實現 我們舉乙個生產nokia的例子 public abstract class nokiaphone先試定義了乙個抽象類,抽象出方法poweronphone 模擬手機開機的動作 public class nokia5200 extends nokiaphone pub...
設計模式 工廠設計模式
工廠模式分為工廠方法模式和抽象工廠模式 工廠方法模式分為 普通工廠模式,就是建立乙個工廠類,對實現了同一介面的一些類進行例項的建立。多個工廠方法模式,是對普通工廠方法模式的改進,在普通工廠方法模式中,如果傳遞的字串出錯,則不能正確建立物件,而多個工廠方法模式是提供多個工廠方法,分別建立物件。靜態工廠...