抽象工廠（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...