寫代碼也有“套路”-談談設計模式

tain335 發布于2019-07-31 10:05 / 2323人閱讀

摘要：所以設計模式其實就是在前人各種踩坑經驗之上，總結出的各種開發套路。但更好的套路是使用單例模式它可以保證只創建一個對象第一次訪問時創建，之后訪問時直接返回已有對象，并提供全局的訪問。因此也有很多人對于設計模式的價值存在質疑。

編程教室開了這么久，已經有很多人從完全零基礎的小白成為了會寫代碼的菜鳥程序員，能夠自己獨立開發程序。不過到此階段，常常會遇到瓶頸，感覺功能可以實現，但代碼看起來有些別扭：

代碼中有很多相似的重復代碼

代碼中有大量的 if，以至于有很長的縮進

單個代碼寫得很長，別人很難看懂，過陣子可能自己都看不懂

總會有沒有考慮到的情況導致 bug

修復一個 bug 又會產生新的 bug

單個功能可以實現，但多個功能組合在一起就理不清

如果需求發生變動，代碼修改起來很麻煩

有多種實現方式時不知道該用哪一種

很難和其他人協作開發

上述的問題你是不是有過類似困擾？解決的辦法其實也簡單，就是堅持“ 多寫 ”和“ 多讀 ”：

多寫代碼。很多時候你覺得不好處理，并不是因為高深的問題，只是你對代碼的基本使用還不夠熟練。同樣的問題，踩過坑再爬出來，反復幾次自然你也知道怎么繞開了。

多讀代碼。除了自己寫，看看別人的代碼也會學到很多。包括教程里的案例、官方示例、開源項目的源碼等。所謂“熟讀唐詩三百首，不會作詩也會吟”嘛。

除了這兩個“笨辦法”外，還有樣東西，對于處在這個階段的你或許有很大啟發，這就是：

設計模式

設計模式是對于軟件開發中常見的一些問題所總結出的解決方案，它并不關注具體的代碼怎么寫，而是 代碼的結構應該如何設計 ，從而讓代碼 更加可靠、可讀、可重用、易于維護 。它不是一種嚴格意義上的“技術”，而是一門“經驗主義”，也就是開發者經常提到的“ 最佳實踐 ”。所以設計模式其實就是在前人各種踩坑經驗之上，總結出的各種開發“套路”。

舉幾個常見的設計模式例子：

單例模式

場景舉例：代碼中需要一個共享的資源管理器，保證在代碼只有唯一的一個實例，且代碼各處都可以訪問到。

如果你的代碼只有一個文件，可能不會遇上這個問題。但當項目大一點之后，這個問題十分常見。你可以選擇定義一些全局變量來實現。但更好的“套路”是使用單例模式：它可以保證 只創建一個對象 （第一次訪問時創建，之后訪問時直接返回已有對象）， 并提供全局的訪問 。

代碼演示


# 單例類
class Singleton(object):
    _instance = None
    def __new__(cls, *args, **kw):
        if not cls._instance:
            cls._instance = super(Singleton, cls).__new__(cls, *args, **kw)
        return cls._instance

# 繼承單例
class MyClass(Singleton):  
    a = 1

# 使用
mc1 = MyClass()
mc2 = MyClass()
print(mc1==mc2)
mc1.a += 1
print(mc2.a)

輸出


True
2

之前我們的文章《Crossin：Python單例模式(Singleton)的N種實現》有專門討論過 Python 中的單例模式實現。

工廠模式

場景舉例：在一個繪圖工具里，有不同的筆刷。當點擊不同的筆刷按鈕時，需要創建對應的筆刷供使用。

如果把每個按鈕響應里都去多帶帶創建，代碼會很冗余且不利于維護。這時可創建一個“工廠”類，將創建筆刷的代碼放在其中， 只需要根據傳入的參數不同，返回不同的筆刷實例即可 。就如同工廠根據訂單生產產品一樣。

代碼演示


# 筆刷工廠，具體類代碼略
def pen_factory(mode):
    if mode == "PEN":
        return Pen()
    elif mode == "PENCIL":
        return Pencil()
    elif mode == "BRUSH":
        return Brush()
    else:
        return None

# 使用
p = pen_factory("BRUSH")

代理模式

場景舉例：開發一個論壇，允許用戶在帖子中上傳圖片，于是需要提供保存圖片的功能。

一般為了網站的訪問速度，會選擇第三方的圖片保存服務。那么在保存圖片的時候，就需要調用其提供的接口。而應用代理模式的話，就會在網站和第三方服務間增加一層。這樣的好處是可以 將一些額外的處理放在代理層中 ，當需要更換第三方服務時， 不需要修改網站的邏輯 ，只要調整代理層即可。

代碼演示


class ImgService:
    @abstractmethod
    def save(self, img):
        pass

# 真實類
class XYZImgService(ImgService):
    def save(self, img):
        # 調用第三方服務接口

# 代理類
class ImgServiceProxy(ImgService):
    def __init__(self):
        self.service = XYZImgService()
    def save(self, img):
        return self.service.save(img)

# 使用
def save_img(img):
    proxy = ImgServiceProxy()
    proxy.save(img)

設計模式的 六大原則 ：

1、 開閉原則 （Open Close Principle）
對擴展開放，對修改關閉。在需求變動時，盡可能不修改原有代碼，而通過擴展實現。

2、 里氏代換原則 （Liskov Substitution Principle）
在使用繼承時，在子類中盡量不要重寫和重載父類的方法。

3、 依賴倒轉原則 （Dependence Inversion Principle）
針對接口編程，細節依賴于抽象。

4、 接口隔離原則 （Interface Segregation Principle）
降低類之間的耦合度，不依賴不必要的接口。

5、 迪米特法則 ，又稱 最少知道原則 （Demeter Principle）
模塊之間相互獨立，對自己依賴的類需要知道的信息越少越好。

6、 合成復用原則 （Composite Reuse Principle）
盡量使用合成/聚合的方式，而不是使用繼承。

具體的解讀，今天沒法在一篇推送中展開詳述，而且這是個需要不斷體會和實踐的事情。首先你可以找些相關書籍讀一讀。設計模式有一本經典書籍：《 Design Patterns: Elements of Reusable Object-Oriented Software 》（《設計模式：可復用面向對象軟件的基礎》）。此書又被稱作“ GoF ”（Gang of Four，四人組），四位業內大牛總結出了 23 種設計模式。

然而，我強烈不推薦新手去看這本書，因為你很可能看不懂。我推薦的是一本叫做《 Head first 設計模式 》的書，可以算作上面那本的白話入門版，對于新手來說友好許多，或許幫助更大。

開發者對于設計模式的理解大致存在這樣幾個階段：一開始只關注語法和庫， 不懂設計模式 ，寫代碼無章法；后來了解了設計模式之后，開始嘗試 套用設計模式 ，懂得重構代碼，但有時難免教條化或陷入過度設計的誤區；等到開發經驗豐富之后， 不再拘泥于所謂的“模式” ，本身寫出的代碼就已經契合設計的原則。

書上的設計模式是一成不變的，不可能涵蓋每一種開發場景，而軟件技術本身也不斷發展，很多模式已經被新的語言特性所實現。因此也有很多人對于設計模式的價值存在質疑。我的看法是，如果你處在新手階段， 學習設計模式是很好的提升方式 ，也可以開拓你的編程思維。而當你已經走上進階之路之后， 更多的應是關注模式背后的原則 ，寫出更合理的代碼，而并非為了模式而模式。

當然這一切，還是都離不開足夠的代碼量。每個程序員都是一行行代碼堆出來。

════

其他文章及回答：

學編程：如何自學Python | 新手引導 | 一圖學Python

開發案例：智能防擋彈幕 | 紅包提醒 | 流浪地球

歡迎搜索及關注： Crossin的編程教室

GPU云服務器云服務器網站架構設計怎么寫也有可能是action 寫代碼自己寫代碼

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/43238.html

編程中的那些套路——關于觀察者模式

摘要：我們應該寫一段拓展性強與維護性較強的代碼，由此衍生出觀察者模式。該文章屬于《編程中的那些經典套路——設計模式匯總》系列，并且以下內容基于語言PHP 今天我們來談談觀察者模式，這是一個經常用到的設計模式。讓我們想象一個場景：一個網站有不同等級區域的用戶，不同等級的的用戶登錄后可以獲得對應的服務（一級用戶登錄后獲得一級服務，二級用戶登錄后獲得二級服務，…以此類推）。那么我們如何寫這段業...

Fourierr 2019-06-27 13:53 評論0 收藏0
編程中的那些經典套路——設計模式匯總

摘要：如果看不懂的話，可以在評論區中提問，我會第一時間回答你無論何時我一直都在嗯哼該文章屬于編程中的那些經典套路設計模式匯總系列在正式閱讀前，我先談談我們該用什么姿勢和心態學習設計模式：如果你還沒有過多的編程經驗（泛指半年以下），我建議你把它當做小說來看，能看懂多少是多少，因為半年以下經驗的程序員用到設計模式的情況只會出現在面試上，至于實際工作中？相對來說這部分不會由你負責。如果你已...

youkede 2019-06-27 13:55 評論0 收藏0
編程中的那些套路——關于適配器模式

該文章屬于《編程中的那些經典套路——設計模式匯總》系列，并且以下內容基于語言PHP 今天我們來談談適配器模式。想象一個場景：有一個類方法它部署在服務器上，專門負責大多數語言都通用的JSON語言，而現在我需要調用這個類方法，但我不需要返回JSON格式的數據了，我要返回序列化后的數據，我現在如何處理呢？是上去服務器修改這個類方法嗎？這不科學吧？因為我們原本編寫好的代碼最好就不要再改了，很容易造成...

gnehc 2019-06-27 13:55 評論0 收藏0
編程中的那些套路——關于裝飾器模式

該文章屬于《編程中的那些經典套路——設計模式匯總》系列，并且以下內容基于語言PHP 今天我們來談談裝飾器模式，想象一個場景：有一篇帖子帖子的內容我寫好了, 三個部門的人員想控制它. 編輯組要添導讀文字審核組要去敏感字市場部想在末尾加點廣告我只是一篇帖子,由你們來處置吧。此時如何處理呢？如何寫出符合面向對象三特性五原則的代碼呢？由此引出裝飾器模式就發揮作用了一言不合來看看代碼：裝...

lavor 2019-06-27 13:53 評論0 收藏0
編程中的那些套路——關于責任鏈模式

該文章屬于《編程中的那些經典套路——設計模式匯總》系列，并且以下內容基于語言PHP 今天來談談責任鏈模式，乍一聽責任鏈模式好像很高級的一樣，但是相信我，其實每位天朝的同學都十分熟悉這個模式，責任鏈模式,就好像中國的官場制度一樣,每一個級別的權利都區分的很細，舉個生活中的栗子：村委不能越級去替鎮委辦事情，如果村委無法解決，只能向上求助鎮委鎮委不能越級去替市委辦事情，如果鎮委無法解決，只能向上求...

lylwyy2016 2019-06-27 13:53 評論0 收藏0