1.1 模式簡介
如前所述,程序員通過設計模型來開始編寫程序:編譯程序將對其進行操作的實體列表。並且程序中的實體越多,程序就越複雜。
因此,為了降低程序的複雜度,他們試圖將對象的交互標準化。而這正是設計模式或設計模式對程序員有很大幫助的地方。源自英文design pattern。
重要的!在俄語中,設計一詞通常表示圖形設計,而在英語中並非如此。英文單詞design在含義上更接近於單詞“design”和/或“device”。例如,發動機的設計不是它的外觀,而是它的內部結構。
因此,設計模式就是設計模式/模式。我建議你完全停止在“外觀”的意義上使用設計這個詞。你是未來的軟件工程師,對你來說設計就是設計。
那麼這個設計模式是什麼呢?首先,設計模式是標準問題的標準解決方案。一個好的、有效的和經過時間考驗的解決方案。
比方說你被要求設計一輛自行車,你可以把它做成兩個輪子,三個甚至五個。所以順便說一句,在設計的初期,它是。但經過時間考驗的方法是兩個輪子。但目前顯而易見的方法經歷了痛苦和錯誤:
![](https://cdn.codegym.cc/images/article/5d016cef-bd5d-42a7-8874-07e416f7f55f/800.jpeg)
通常,模板不是可以直接轉換為代碼的完整解決方案,它只是一個很好的解決問題的示例,可以在各種情況下使用。
面向對像模式顯示類或對象之間的關係和交互,而不指定將使用哪些最終類或應用程序對象。
1.2 設計模式的歷史
早在 70 年代,程序員就需要開發大型程序,而這些程序必須由整個開發團隊共同完成。嘗試了各種組織工作的方法,但建築業對發展的影響最大。
為了組織一大群人的工作,使用了建築行業的實踐和方法。順便說一句,程序集(build)、Software Developer(builder)和架構的概念就是從那裡開始進入編程的。
正如你已經猜到的那樣,設計模式的思想也來自於建築行業。模式的概念首先由 Christopher Alexander 在模式語言中描述。城市。建築。建造”。在這本書中,一種特殊的語言,模式,被用來描述城市設計的過程。
建築模式描述了典型的經過時間考驗的決定:窗戶應該有多高,建築物應該有多少層,微區應該為樹木和草坪分配多少面積。
因此,1994 年出版《面向對象設計技術》一書也就不足為奇了。Design Patterns”,其中包括 23 種解決面向對象設計各種問題的模式。
這本書由 4 位作者撰寫:Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides。書名太長,誰都記不住。因此,很快大家就開始稱它為“book by the gang of the four”,即“四人幫的書”,後來甚至被稱為“GoF book”。
從那時起,其他設計模式就被發現了。“模式”方法在編程的所有領域都變得流行,所以現在您可以在對象設計之外找到各種模式。
重要的!模式不是一些超級原創的解決方案,相反,它是經常遇到的、針對同一問題的典型解決方案。經過驗證的良好解決方案。
1.3 模式列表
許多程序員一生都沒有學習過一種模式,但這並不妨礙他們使用它們。正如我們之前所說,模式是經過時間考驗的好解決方案,如果程序員不是傻瓜,那麼他自己會根據經驗找到這樣的解決方案。
但是,既然有人已經走過這條路,並把他們的經驗和人生智慧寫成書,為什麼還要經過幾十次試錯,得出最優解呢?
你可以用扳手敲釘子,但為什麼呢?如果你努力的話,你甚至可以使用鑽頭。但是,有意識地擁有樂器正是專業人士與業餘愛好者的區別所在。而專業人士都知道,鑽頭的主要特點根本不在這。那麼,為什麼你需要了解模式?
- 經過驗證的解決方案。您花更少的時間使用現成的解決方案,而不是重新發明輪子。有些決定是您自己想到的,但許多決定對您來說可能是一個發現。
- 代碼標準化。使用典型的統一解決方案進行設計時,您的計算錯誤會更少,因為其中隱藏的問題早就被發現了。
- 通用編程詞典。您說出模式的名稱,而不是花一個小時向其他程序員解釋您提出了多麼酷的設計以及為此需要哪些類。
圖案是什麼?
模式在所設計系統的複雜程度、細節和覆蓋範圍方面有所不同。打個建築類比,你可以通過設置紅綠燈來增加十字路口的安全性,或者你可以用帶地下通道的整車立交來代替十字路口。
最低級和最簡單的模式是習語。它們不是通用的,因為它們僅適用於一種編程語言的框架。
最通用的是幾乎可以用任何語言實現的架構模式。他們需要設計整個程序,而不是它的單個元素。
但最主要的是模式的目的不同。我們將熟悉的模式可以分為三個主要組:
- 創建模式負責靈活地創建對象,而不會在程序中引入不必要的依賴關係。
- 結構模式顯示了在對象之間建立關係的不同方式。
- 行為模式負責對象之間的有效通信。
1.4 UML簡介
讓我們先看看《四人幫》一書中描述的相同的 23 種模式。即使對於新手程序員來說,模式本身和它們的名稱都是熟悉的東西。我會向您介紹它們,但我強烈建議您閱讀那本關於模式的書。
設計模式不依賴於特定的編程語言,因此通常使用 UML 來描述它們。它在 20 年前非常流行,但即使現在有時也會使用。順便說一下,模式的描述只是使用 UML 的標準。
使用 UML,您可以描述不同實體之間的關係。在我們的例子中,這些是對象和類。
類之間的關係由四種類型的箭頭描述:
![]() |
組合(組合) - 聚合的一個亞種,其中“部分”不能與“整體”分開存在。 |
![]() |
聚合- 描述“部分”-“整體”的關係,其中“部分”可以獨立於“整體”存在。菱形是從“整體”一側表示的。 |
![]() |
依賴- 一個實體(獨立)的變化會影響另一個實體(依賴)的狀態或行為。箭頭的一側指示了一個獨立的實體。 |
![]() |
泛化——接口的繼承或實現的關係。箭頭的一側是超類或接口。 |
其實這裡的一切都很簡單。最後一個箭頭實際上表示一個類繼承自另一個類。而第一個和第二個箭頭是一個對象存儲到第二個對象的鏈接。這就是全部。
如果鏈接菱形是黑色的,則鏈接很弱:對象可以獨立存在。如果菱形是白色的,那麼對像是強相關的,比如一個類HttpRequest
和它的子類HttpRequest.Builder
。
1.5 模式列表
圖案類型將由不同的顏色和字母表示:
乙- 行為的(behavioral);
C- 生成(創造);
小號- 結構(結構)。
最後,列出 23 種設計模式:
C- 抽象工廠 小號- 適配器 小號- 橋 C- 建設者 乙- 責任鏈 乙- 團隊 小號- 鏈接器 小號- 裝飾師 |
小號– 立面 C- 工廠方法 小號- 機會主義者 乙- 口譯員 乙- 迭代器 乙- 中介 乙- 守護者 C- 原型 |
小號- 代理人 乙— 觀察員 C— 孤獨者 乙- 狀態 乙- 戰略 乙— 模板方法 乙— 訪客 |