抽象工廠(abstract factory):提供乙個建立一系列相關或相互依賴物件的結構,而無需指定他們具體的類。
抽象工廠uml圖:
abstractproducta和abstractproductb是兩個抽象產品,它們可能是兩種不同的實現。在機房收費系統中可以理解為對兩個表的不同操作。
而producta1和productb1可以理解為sql的操作,producta2和productb可以理解為access的操作。因為producta1和productb1是依賴concreatefactory1,所以concretefactory1可以理解為sqlfactory,同理右邊concretefactory1(應該為concretefactory2)可以理解為accessfactory。
通常是在執行時刻在建立乙個concretefactory類的例項,這個工廠在建立特定的產品物件,為建立不同的產品物件,客戶端應使用不同的具體工廠。
在機房收費系統中:
通過工廠建立了藉口,去實現介面。就相當於上圖中的concretefactory1去建立了producta1和productb1。這裡我沒有抽象,只是用了抽象工廠的一部分功能,這裡的dalfactory是sqldalfactory,如果存在將來把資料庫換成oracle,就可以抽象出乙個抽象的工廠,就是上圖中的abstractfactory。在有不同的實現,從而實現出oraclefactory,dalinte***ce中的一些抽象和實現和工廠是同理的。
這樣做的好處就是易於交換產品系列,是變化資料庫變得更簡單。
看到了抽象工廠,又重新看了一遍工廠模式還有簡單工廠模式。
簡單工廠:
這個簡單工廠很簡單了,只是利用簡單工廠中的select case根據不同的條件去創造不同的類。如果新增其他操作,必須修改工廠,這個違反了開放封閉原則。而工廠模式很好的克服了這一困難。
工廠模式:
uml圖
在工廠模式中,把原來的簡單工廠變成了抽象工廠。如果新增乙個新的功能,只需在抽象工廠的下面新增乙個子類,去繼承抽象工廠,從而解決了簡單工廠中的新增功能問題。這裡只需新增,而不用去修改原來的工廠。
簡單工廠的好處是自動判斷了必要的邏輯判斷,根據客戶端的選擇條件動態例項化相關的類。
而抽象工廠比工廠模式只是在具體實現的時候又多了乙個抽象,可能這樣說不是很專業。可以理解為具體工廠在例項化一些類時,被例項化的這些類之間有一些相關的聯絡,從而在例項化的類之間在抽象出抽象類。
工廠這個東西看似簡單,但是往往簡單的東西包含著大道理。千萬別小覷它。
ps:部分uml圖來自《大話設計模式》
機房收費系統之結尾
機房收費系統在這個冬月告乙個不完美的結局,剛開始接觸他的時候,各種糾結,各種逃避,各種不想做,接觸乙個新的事物,內心充滿了恐懼與排斥,機房收費系統與學生管理系統不一樣,沒有原始碼,這個時候,需要自己不斷的給予自己鼓勵,七 期的師哥師姐都做出來了,你完全有理由相信,自己也能做出來。機房收費系統來來回回...
機房收費系統之思路
機房收費系統的資料放在手裡已經有好一段時間了,卻遲遲沒有開始動工。不知道是對它產生的牴觸心理,還是自己本身就好懶。總是放著不肯前進。但是這幾天看到同學們的進度都好快,有的甚至都已經結束了。不能再偷懶了,話說進度不用太趕,但是自己心裡還是很著急的。畢竟大家的起跑點都是一樣的,怎麼能夠在半路落在別人身後...
機房收費系統 之 結賬
結賬,顧名思義就是把錢算一下。這的結賬不是給每乙個卡號結賬,而是給乙個操作員結賬,算一下這個操作員一共賣卡張數,退卡張數,實收金額,應收金額等等。結賬的介面是這個樣子的,其中用到乙個選項卡 這個窗體相比較而言還有有點難度的。別看乙個小小的操作員使用者名稱,它不是一般的combo控制項,對於一般的co...