還記得照葫蘆畫瓢嗎？在敲機房收費系統的時候的確是照著三層加上自己的理解來敲的，整個過程下來就是完全照葫蘆畫瓢的。但是第一次成型，出現問題的時候，請教了別人。他將我的錯誤指出來，以及我自創的三層架構。看了看別人的，我的簡直不堪入目。別人長得是葫蘆，我這本來是葫蘆根，長出來的確是絲瓜，四不像。之後忍受各種打擊，堅強的把這葫蘆整形，整過來了！南韓美容技術不錯，我這美容技術自我感覺良好。一下便是整容後的成果。
首先是一張uml圖。一張圖把重心表達出來，自己的方向也就不會走偏了！
這張uml圖，幫了我不少的忙。最初懵懂的我逐漸清晰的認識到三層應該是什麼樣子的。話說原理都能聽懂看懂，但是等自己實踐的時候就不是這個樣子了。
在u和b層之間，用了乙個外觀模式，外觀模式大家還能想起來吧，大概就是將一致的東西打包一下，每次放假回家公尺老師都會說我們不要打包小包領回家，要將東西打包一下，這樣既簡單又好找。在這裡外觀模式就是起到這麼乙個作用，我們都知道在b層中我們寫的是各種實現的方法過程，但是有很多實現似的，比如對卡的操作，對學生的操作，等等我們 可以進行分類，也可以根據對資料庫的增刪改查進行分類。
還有就是在b層和d層之間，現在的兩層並不是相互聯絡的，而是通過工廠，介面進行聯絡，這樣體現物件導向的開放擴充套件原則。同時在這張圖中大家能看到entity這個例項，這個例項是被抽象出來的，因為 在各個層都要用到，從這裡也可以體現到物件導向。
通過敲**，雖說物件導向和面向過程在理論上可以區分，但是當我們在敲**的時候，很難注意到，所以圖還是乙個很重要的輔助工具，以防我們跑偏。
首先 是u層**：
private void cmdlogin_click(object sender, eventargs e)
catch
}
public class loginmanager
}
public class sqluser : inte***ce.iuser
modle.id = reader.getint32(0);
modle.username = reader.getstring(1);
modle.password = reader.getstring(2);
}return modle;}}
}
namespace factory}}
namespace inte***ce
public inte***ce ifactory
}
這個登陸經歷醜陋不堪到還算對的起大眾這個過程，自己每次開啟vs的時候，有時候會忍不住開啟這個小例子，讓他在執行一次，看著都很欣慰，很有動力。整形師的技術雖有待提高，但是我堅信我會做的更好。沒有乙個痛苦的經歷，我的收穫有源自**呢？
機房重構 抽象工廠 反射 配置檔案（上）
被抽象工廠在重構中的運用困擾好久了，現在終於理清了一些頭緒。下面我就分享一下這一階段我所遇到的一些問題以及解決方法。通俗的講，配置檔案就是程式執行時需要用到的一些設定以及引數，它和程式一起安裝到計算機上。通過配置檔案，開發人員可以按需要對其做修改，而不必改變程式 就可以達到某種目的。配置檔案是標準的...
工廠模式（簡單，配置檔案，反射，工廠方法，抽象）
簡單工廠模式的缺點，把矛盾集中在簡單工廠類中，使工廠類高耦合，而且進行修改和新增的時候也會比較麻煩。簡單工廠模式的優點，結構更加清晰，使 容易維護和分工明確，如下 namespace designmode public enum traffictype 下面是簡單工廠的意識圖 工程模式加上配置檔案的...
工廠模式 反射 配置檔案
inte ce fruit public void eat class orange implements fruit 構造工廠類 也就是說以後如果我們在新增其他的例項的時候只需要修改工廠類就行了 class factory if orange equals fruitname return f c...