設計模式與抽象 一

2021-09-25 22:13:12 字數 3346 閱讀 2689

設計模式:

無數碼農前人在實際的生產專案中經過不斷的踩坑、爬坑、修坑的經歷總結出來的經驗教訓,經過抽象之後表達成的概念。

理解:

不好理解,實際上並不是你看不懂,而是你不明白為何要如此「故弄玄虛"。這個很好明白,等你真正經歷大型專案開發、迭代、重構、甚至重寫之後,你就會贊同這些能寫出設計模式的人,是多麼的**遠矚,多麼的有智慧型。

本質:

一言以蔽之,設計模式的本質就是:將軟體中變化的部分和不變的部分分開。

掌握:

要從整體結構上、從本質目標上、從思想體現上來把握,而不要從區域性、從表現、從特例實現上來把握。

軟體生命週期:

軟體產品從概念階段到最後的面向使用者的過程中,不是意味著產品的生命週期就結束了!以後還會有產品功能的擴充套件,還會維護產品,還需要重用產品的一些已有成果。

也就是我們所說的易擴充套件性,可維護性,可復用性!為了實現這個就需要從軟體設計時分層和分割的時候做到高內聚低耦合!

設計模式:

23種設計模式就是從構建,行為,結構的角度來設計的一些類之間的關係抽象。從而從一定程度上實現高內聚低耦合,進而達到可擴充套件性,可維護性,可重用性。

三十六計玄不玄?也玄!

那兩三千年來世界其他國家沒看過

<

三十六計

>

是怎麼打仗的?照樣打。沒學過三十六計的人就不會使用裡面的計策嗎?當然會用,而且經常用。只是不知道古代已經把它總結成「戰爭模式」了。比如「借刀殺人」,相信這個人們在耍小聰明的時候都用過;「打草驚蛇」這個計策估計連小孩都會用,還有很多。

沒學過設計模式就沒有使用過嗎?非也!

一樣經常用到,只是你不知道前人已經寫成書。設計模式雖然名字很玄,並且可能你沒看過相關的書籍,但不代表你沒有用過。

比如你在寫共享乙個例項的時候你可能已經用到了單例模式,當你想要相容時可能已經用到了介面卡模式,當你組合某個控制項時你已經用到了組合模式等等。

第一階段:手中無劍,心中無劍

聽別人說到「設計模式」感覺特別高大上,自己不太懂,也用不太起來。

第二階段:手中有劍,心中無劍

經典23

式開始一招一招比劃。但此時手中雖有了重劍,卻不太能舞起來。

缺乏實際經歷的應用場景去做參考,看著書中的例子很難感同身受,很難引起共鳴,而且很有可能模式的描述和場景壓根就不太明白。

第三階段:手中有劍,心中有劍

隨著自己的學習和開發經歷的豐富,已經對設計模式有一定理解了。在閱讀開源**,你經常可以發現可以對應於某模式,你逐漸明白了某個模式用在某個地方能起到什麼作用,你經常會有一種

"wow"

的趕腳。

在程式設計過程中,能夠照貓畫虎的用設計模式了。而且你開始學習物件導向設計原則,比如

solid

原則也有了一定的理解。你跟別人討論時,可以大聲地說:讓我們使用乙個

xx模式來支援更好的擴充套件性吧。你時不時會回頭去看

《設計模式

》,除了能夠提供參考,此時你會有一些新的體會了。

第四階段:手中無劍,心中有劍(人劍合一)

已經有設計和架構的概念了,這時你已經開始面對乙個幾萬行甚至幾十萬行的專案,有一天你發現**已經很難快速響應需求變化了,又沒辦法推倒重來,所以來重構吧,重構的過程中,乙個個設計模式把**維護中的乙個個痛點逐個擊破,你對**的「

smell」

有了更深刻的理解,你開始對

copy-paste

**深惡痛絕,你發現原來重構和設計模式竟然是孿生兄弟。

開始明白乙個長期維護和演化的專案,設計如此之重要。 「面向介面程式設計」,「組合優先繼承」,多麼樸素的文字,或許很多人都能說出來,但是你確定你現在的理解更加深刻了。

你會發現,此時你手中已經無劍了,你不會想著什麼模式列表了,不會想著某個模式重要了。

進行乙個複雜設計時,不自覺地就從軟體開發的終極目標「高內聚低耦合」出發,「面向介面程式設計」,「組合優先繼承」,「建立與使用分離」等認知成為本能反應,結合需求場景,每定義下乙個類都有「開放封閉」等各種物件導向設計原則護體,隨著專案演進,你能敏銳地嗅到各種**

smell,

知道如何考慮現有資源去減少該死的技術債,隨時進行著重構。

有一天,

有人問你,怎麼

state

模式和strategy

模式的類圖是一樣的? 你裝逼地笑了笑,說到:這些不重要,心中有劍就能無往不勝。

什麼是抽象?

個人認為抽象應該是抓住事物本質,然後剝離出來在更為寬泛的條件下進行模擬演繹的過程。

真正的高手就是要把簡單的事情先複雜化(全面、周全、系統),然後

——抽絲剝繭,再把複雜回歸到簡單。

從簡單到複雜,體現的是系統化,全面性。

從複雜到簡單,則更多要進行抽象化思考。

抽象就是從表面看到本質,從片面看到整體,然後抽出那些穩定的、共同的特徵。

抽象能力重要嗎?

寫**需要抽象能力,無比需要。如果你不想一輩子都做乙個碼農,如果你想寫出來一些自己也感覺到滿意的**,如果你想未來不被更高階的編碼工具取代,你需要學會抽象。

花半秒鐘就看透事物本質的人,和花一輩子都看不清事物本質的人,注定是截然不同的命運。

抽象能力,決定著對事務的認知分析。

看山是山、看水是水

看山不是山、看水不是水

看山還是山、看水還是水

對於 10

w 行以下的**量的漢子來說,設計模式

=玄學。

對於 10

w ~ 50w

行**量的漢子來說,設計模式

=科學。

對於 50

w 行以上**量的漢子來說,設計模式

=文學。

1.尋找事物的巨集觀結構,所謂格局: 格局,無非是不同層次事物間的連線,過濾掉不需要的細節,抽取出乙個巨集觀結構。

2.結果導向的思維: 模型都是在講輸入和輸出,你設計乙個模型把一定的輸入變成一定的輸出。 這種思維和「跟著感覺走」是截然相反的過程。

3.確立邊界及簡化理論: 所有物理定律都有明確邊界,而對邊界以外的東西盡量不觸碰。

設計模式學習與整理 抽象工廠模式

是圍繞乙個超級工廠建立其他工廠。該超級工廠又稱為其他工廠的工廠。這種型別的設計模式屬於建立型模式,它提供了一種建立物件的最佳方式。1 系統需要為使用者提供多個物件,但不希望使用者直接用new運算子例項化這些物件,即希望使用者和建立物件脫耦。2 系統需要為使用者提供一系列物件,但只需要知道這些物件有哪...

設計模式之(一)抽象工廠模式

我理解的抽象工廠模式其實就是為物件提供建立介面,呼叫建立介面就能得到想要的物件。舉例 比如說需要和文字轉換類,傳如文字內容獲取路徑和名稱,需要得到 或文字 的html標籤或者是 或文字 的json decode資料,在如下圖的抽象工廠模式中,我們只需要呼叫業務工廠類 htmlfactory或json...

設計模式 抽象工廠模式

抽象工廠模式,在很多場景下都有應用。它有以下的優點 1 封裝性,每個產品的實現類不是高層模組要關心的,它所要關心 的是介面和抽象類,他不關心物件是如何建立出來,只有工廠類去關心,只要知道工廠類是誰,我們就能得到乙個需要的物件。2 產品家族的約束為非公開狀態。而抽象工廠模式針對的是多個產品等級結構。當...