宅男程序員給老婆的計算機課程之5:設計模式
原創設計模式，應該是很多ED心目中牛B的編程方式。
上回說到ED的好書POEE，實際上便是一本專門講企業開發中使用的設計模式中的書。
設計模式，并不多，基本上看完GoF的這邊《Design Pattern》便可以有足夠了解了。
而實際開發中常用的設計模式更是屈指可數，Singleton，Factory，Facade，Active Record、Provider等等。
就那么幾個，花花功夫，仔細了解一下這幾個，然后在實際編碼中應用一下，便可以算是掌握了。
設計模式，并不難。
它是開發中非常必要的知識，實際上，是非常基礎的知識，并不牛B。
開發的時候，需要時刻明確自己的目標：解決問題。
解決問題才是最重要的。
設計模式的存在，是為了更好的維護、管理代碼，或者是為了擴展性；絕對不可以為了設計模式而模式。
在Java程序中，為了模式而模式的現象蠻普遍的。
我猜想這是因為Java是一門工業語言，有大量的ED使用的緣故。
ED把設計模式的使用，當成是一種可以炫耀的編程技巧，或者說，他們遵從的編碼規范中，要求他們去使用某某設計模式。
至于為什么要使用設計模式，最常見的理由便是：為了將來可以XX，或者YY。
程序開發中，有一句名言：“Pre-mature optimization is the root of all evil”。
過早優化，是萬惡之源。
非常多的情況下，將來預想中的XX或者YY；并不會發生。大部分代碼，寫了之后就會被丟棄掉，再也不會有人去維護。
當XX或者YY發生的時候，往往，都是會推倒重來。
除非你很牛B，只有牛到一定程度，才有可能對將來可能發生的情況做好合理的預測，并預留出改善、調整的空間。
但非常諷刺的是，為將來做設計的最好方法就是：什么都不做。
只有空白，才能夠留下最大的發揮空間。
現在為將來可能發生的情況，做了編碼，任何一行編碼，都是很可能是在為將來添加限制、制造麻煩。
現在寫下去的代碼，將來，都是要被刪掉的；能夠不寫，就不寫。
在任何時候，都應該保持代碼簡潔。
函數，盡可能的短；當一個函數的長度，超過一個屏幕的時候，便應該考慮重構、拆分。
牛B的程序，都應該是簡單、易懂的；采用大量的設計模式，復雜得讓人無法直接看懂，或許有它的意義以及應用場景，但這絕對不是編程功力牛B的表現。
打個比方，設計模式就是武術招式。
學徒，必然需要熟悉什么“有風來儀”或者“屁股朝后平沙落雁式”。
但更高的境界是：無招勝有招。
簡單、直接的把代碼搞定。
Python大牛沈崴有云：“得道的程序員，既不封裝，也沒有重復代碼。”
http://eishn.blog.163.com/blog/static/6523182010102342531684/
作業：
1. 使用一種編譯語言實現 Singleton 模式
2. 使用一種動態語言實現 Singleton 模式
3. 說說對 Provider 模式的理解。
男主角：Wuvist（新浪微博），真名翁偉，自稱胖程序員一個，幸好已婚。學習.NET
本文作者：Wuvist
女主角：Katze，Wuvist的老婆，女程序員，
51CTO系列：
