初學者設計模型

已發表: 2016-01-13

如果您已經為產品或軟件應用程序編寫過程序，無論大小，您很可能使用過很多設計模式……儘管它們可能不是最常用/標準的設計模式之一。

但是，是的，實現設計模式和“使用”設計模式之間有明顯的區別……無論哪種方式，使用設計模式的人都理解它，或者很容易理解它。

關鍵是，設計模式對程序員來說並不新鮮。

在下面的這篇文章中，我試圖解釋設計模式的基礎知識，我們將在另一篇文章中研究各種模式、示例等的細節。

什麼是設計模式？

開始…

我認為從理解設計模式開始的最好方法是理解我們在日常生活中有意/無意地遵循的非技術模式。

例如，讓我們為一個職位空缺提交大量的簡歷。每個人的簡歷看起來都不一樣……儘管他們都傾向於做同樣的事情，那就是告訴讀者他們擅長什麼，或者他/她如何適合這份工作。

大多數向工作提交簡歷的人都知道，他們需要在格式化的 Word 文檔中提交包含特定信息集的簡歷。

這……是一種模式，每個人都會提交一份簡歷，其中包含一組特定的信息。

如果你覺得……稱之為模板而不是模式。設計模板。

現實生活中有很多這樣的事情是模式。有些人喜歡下面的例子：

全球所有廚師都以同樣的方式烹製比薩餅或炸薯條。雖然他們可能會在上面/味道不同。那是一種模式。

每輛車的設計都遵循一個基本的設計模式，四個輪子、方向盤、油門-剎車-離合器等核心驅動系統。

所有重複建造/生產的東西，都不可避免地會在其設計中遵循某種模式……無論是汽車、披薩、ATM 機，等等……甚至是牙刷。

幾乎已成為在軟件中編碼某些邏輯/機制/技術的標準方式的設計，因此被稱為 - 並因此 - 被研究為軟件設計模式。

為什麼設計模式很重要？

基本上有兩個原因：

堅持一個標準
加快發展

我會詳細解釋。

首先，我們明白為什麼堅持標準模式很有趣。

讓我們以我們之前討論過的簡歷示例為例。

可能有一兩個申請人通過電子郵件文本發送他們的工作申請，沒有適當的格式，沒有附件到他們的電子郵件等，..這一兩個申請人沒有遵循模式..並且不太可能最終隨著工作...... 為什麼？ 因為他們偏離了一個既定的模式，這可能不被那些為這份工作列出簡歷的人所喜歡。

沒有人會偏離模式變“酷”嗎？這不就是創新嗎？

是的，有時候，一份非常不同的簡歷會因為與其他人不同而獲得這份工作。通常我聽說過一些網頁設計師找到了主要工作，因為他們編譯並展示了他們工作的 CD 電影，或者製作了一個動畫角色來解釋他們的工作，把它放在他們的博客上，等等。

但是..這是實驗（創新來自成功的實驗）。

大多數情況下，在軟件開發中，由於時間壓力、期望等原因，您無法承擔實驗費用，但有時，一些有趣的項目確實允許進行一些實驗。

在軟件中，我們不能做諸如銀行存款之類的基本事情……以 101 種方式……處理銀行存款的方法只有幾種……所以遵循一個既定且經過測試的模式是有意義的。

此外，大多數設計模式都有變體……其中一些變體非常流行，以至於這些變體也將成為該模式的新標準類型。

如今的軟件項目預計（至少隱含地）將遵循市場上已經建立的類似產品/軟件的設計。

這就是堅持標準編碼風格或設計模式有助於軟件開發的地方......加快開發，消除擔心新的未經測試的實現的開銷等，

加快開發時間

遵循標准設計模式還具有通過軟件架構師、模塊負責人、團隊負責人、開發人員等的樹/層次結構輕鬆交流的優勢，關於“如何”開發某些東西，而不僅僅是“必須是什麼”發達。

有時它甚至可以幫助測試團隊，因為測試人員會根據經驗知道，遵循特定設計模式的代碼可能可以在特定時間段內使用一組測試工具以特定方式進行測試，而這種已知設計可能沒有一些缺陷或有一些“已知”的缺陷。

使用設計模式不會帶走個人風格嗎？

不。首先，因為我們並不是說您遵循設計模式並且沒有其他任何事情發生。大多數項目實施只與其他項目共享基本要求，並且很可能會有偏差。構建這些偏差將需要彎曲和拉伸實現中使用的標準模式。

這就像以標準方式製作比薩餅，然後根據不同的要求對其進行調味/呈現，例如完整的餡餅比薩餅，或切好的餡餅，或其他任何東西。

在理解設計模式的重要性時，有一點非常重要：

設計模式不是特定公司或編程語言強加給我們的任何技術或框架。這意味著，它就像一個開放的概念......你可以自由地接受它，使用它，根據你的需要修改它，重要的是......感覺它是你自己的。

實際上，所有標准或流行的設計模式都具有很強的可擴展性。它們之所以流行，首先是因為很多人使用它。而且很多人使用它只是因為它們可以靈活地滿足他們的要求。

或者您認為標准設計模式如何適合新澤西州的公司項目以及班加羅爾的不同公司和不同類型的項目。

這使我們想到“大多數設計模式都是通用的”……這意味著它們並不總是用於構建相同類型的軟件。您可能聽不到常見討論中使用的“銀行軟件設計模式”或“社交網絡軟件設計模式”之類的東西……而只有“設計模式”。

誰應該為設計模式而煩惱？

就像一個優秀的建築架構師如何提高他/她的建築設計技能一樣，通過在他/她的一生中研究無數建築物和形狀的架構和設計，軟件架構師應該研究和想像全球不同的軟件/技術系統是如何設計的或架構的。
就像建築物的建築工人應該如何從自己的經驗或從建築物的建築師那裡了解實現建築設計的不同方式一樣。

軟件開發人員/程序員應該了解基本的軟件設計模式及其實現代碼……無論是他們自己還是來自指導團隊按照特定模式開發它的軟件架構師。

基本代碼模式

在本文的開頭，我說過任何程序員都會使用設計模式。以下是一些遵循模式的非常基本的代碼示例。

以下是一個基本的攔截過濾器設計模式。
隱藏複製代碼
[代碼]
開關（條件）{
案例價值1：
案例價值2：
默認：
}
[/代碼]
事件觸發器、事件處理程序......屬於基本的主題觀察者設計模式。我們將很快討論每種模式的標準、流行的變體以及示例。
如果您使用過某種集合，例如 C# 中的 Arraylist，並遍歷該數組，那麼您就使用了基本的迭代器設計模式。
以下代碼是基本異常處理/責任鏈模式的示例。
隱藏複製代碼
[代碼]
嘗試{
}catch（異常前）{
}
最後{
}
[/代碼]

設計模式的不同領域

除了設計模式之外，軟件中有不同的術語。其中一些通常與我們迄今為止討論的設計模式相關。還有一些完全不相關。

到目前為止，我們在上面討論的內容有時被稱為“實現設計模式”。

還有其他的，比如架構模式、框架模式、語言模式（主要稱為語言結構）。

它們是放置在不同層次上的模式……就像語言模式是作為 C#/Java 等編程語言的一部分實現的模式，作為語言的特性/結構……我們已經看到了其中的一些。

上述所有主題觀察者、攔截過濾器等示例，都被吸收為 C 之後所有流行的高級編程語言中的語言結構。

架構模式是軟件架構的標準模型，通常指的是放置或鏈接模塊或層或層的不同方法，以構成完整的應用程序。

這與編碼/編程意義上的設計模式完全無關……但它們對本文中討論的為什麼/什麼的答案相同。

框架模式也與我們對設計模式的討論無關。當 .NET 等框架通過框架的內置方法或對象輕鬆實現記錄錯誤或跟踪代碼執行路徑的特殊方法時，此類機制稱為框架模式。

.NET Framework 中的一些示例包括 stackTrace 功能、在類/方法定義之上帶有 [] 方括號的類屬性功能等。使用這些功能時，我們使用框架的內置模式進行編碼。

我希望這篇文章有助於提供設計模式和相關術語的概述。

到目前為止，我們只討論了標準是什麼以及它們的重要性。但我們沒有討論標準模式本身是什麼。

執照

本文以及任何相關的源代碼和文件均根據代碼項目開放許可證 (CPOL) 獲得許可。