宅男程序員給老婆的計算機課程之5:設計模式

時間 2020-04-07

標籤程序員老婆計算機課程設計模式欄目快樂工作简体版

原文原文鏈接

設計模式，應該是不少ED心目中牛B的編程方式。程序員

上回說到ED的好書POEE，實際上即是一本專門講企業開發中使用的設計模式中的書。編程

設計模式，並很少，基本上看完GoF的這邊《Design Pattern》即可以有足夠了解了。設計模式

而實際開發中經常使用的設計模式更是屈指可數，Singleton，Factory，Facade，Active Record、Provider等等。服務器

就那麼幾個，花花功夫，仔細瞭解一下這幾個，而後在實際編碼中應用一下，即可以算是掌握了。架構

設計模式，並不難。運維

它是開發中很是必要的知識，實際上，是很是基礎的知識，並不牛B。ide

開發的時候，須要時刻明確本身的目標：解決問題。函數

解決問題纔是最重要的。學習

設計模式的存在，是爲了更好的維護、管理代碼，或者是爲了擴展性；絕對不能夠爲了設計模式而模式。優化

在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出身，現經常使用Python作服務器端開發，曾任新加坡某創業公司主程。公司被Techcrunch blog事後，以爲新加坡生活太過安逸，終於在去年辭職隻身回家鄉汕頭創業，活躍於珠三角技術沙龍，熱衷於與其餘技術宅分享。