關於模式爭論的一點點思考
我是一位C++程式設計師,最近在瞭解模式方面的知識,讓我沒有想到的是,在模式和OO方面,會有這麼熱烈的爭論。
當然,我發現在JAVA界,尤甚。
首先說說我為什麼會關心設計模式,最直接的是我聽說過這個東西,然後發覺這個東西確實為我的軟體開發工作
指了一條路,至少我發覺它可以開闊你的眼界。其次是我在開發工作中遇到了問題,由於缺乏設計,做成的軟體
擴充套件行和可維護性很差。舉個簡單的例子,我的一個專案中,由於資料層和表現層沒有很好的分離,後來軟體升
級,資料的組織形式和訪問機制已經改變,為了適應這個改變,很多東西需要重寫,包括展現層,而對於展現層,
其實並沒有多大的改變!我想如果我當初多點考慮軟體的設計,我想是可以把修改降到最低的。這只是一個簡單
的例子,實際開發中遇到的問題遠不止這些。
所以我開發關心設計,學習一些設計模式,嘗試把它應用到實際的開發中。但是讓我意想不到的是,在模式,OO
的運用上,存在這麼多的分歧,而且當我跟朋友討論起模式的時候,他正告我說小心走到模式的學院派裡。於是
我開始關注這個問題。
於是我嘗試問自己幾個問題:
1,模式是什麼東西,他可以給你帶來的是什麼。
2,應用模式到你的開發中,會有哪些負面的影響?
要回答這些問題,對於我現在的水平,顯然是不容易的。所以這裡寫的,只能算是記錄自己的心路歷程,而
並非經驗總結。
1,模式是什麼東西,他可以給你帶來的是什麼。
這個問題相信有參與討論的程式設計師都有自己的理解。我的理解是模式是特定場景下的特定問題的解決方法的指導。
離開了場景和問題,也沒有模式一說。這些指導方法哪裡來的,正確嗎?它來源於豐富程式開發經驗的程式設計師的
經驗總結。是的,它是一個經驗總結,是有經驗的程式設計師們總結出來的解決特定問題的方法,這些方法的好處一般
是提高模組複用性,減少模組間耦合,增強擴充套件性等。它給你帶來的最直接的就是提供給你一個解決特定問題的方法
,不是嗎?那麼你是否需要使用它呢?用不用,取決於你的判斷,你的問題和你的開發場景。首先你要判斷該模式是否
適用於你當前的問題,context和question是否一致,解決方法跟你的系統有沒有什麼衝突?在判斷為適用的情況下?
就是否需要用這個模式來解決這個問題呢?下面我們會分析這個問題。
2,應用模式到你的開發中,會有哪些負面的影響?
模式的缺點,一般都是由於它的優點所引起的,只所以成為模式,必有它的可取之處,我的理解是一般在提高模組復
用性,減少模組間耦合,增強擴充套件性等方面起積極作用。但是這樣的好處並不是免費獲得的,首先,從寫程式碼的角度來
說,你可能要寫花費更多的時間去實現,有些簡單的問題,或許你用過程化的解決方法,可以很快得到解決,但是運用
模式,你必須要分析你的應用場景,抽象你的問題,還需要理解你所使用的模式,掌握它,實現它。其次,由於模式一般
會在擴充套件行和複用性方面去考慮,程式碼的執行效率有時候就會必你直接的過程化實現要低,佔用的資源也可能會上漲。這個
你就要考慮你是否可以承受。
為什麼TCP的實現沒有用OO的方法,為什麼作業系統很少提供OO的API,為什麼CPU也只是一條條
的執行指令,而沒有提供更高的封裝模型?這些情況延續到今天。
500個平方的豪宅,旋轉式設計,當然你可以控制它的旋轉速度或者是否旋轉,智慧化的家居擺設,全可由遙控器控制,
智慧化的飛機起落平臺,不需要的時候可以智慧摺疊。。。。所有的東西,基本上都可以應需而變,只要你喜歡。
但是,如果你只是一個旅客,只需要在這裡住一晚,你是否樂意去住這樣一個豪宅,如果你只是一屆平民,口袋裡只
有百來塊錢,你是否認為這樣的房子有必要存在?更有甚者,如果我根本不懂什麼是高科技,而且我口袋裡根本沒錢,
難免我不會產生仇富思想,恨不得這個房子馬上跨掉。。。。
人人都知道高階豪華小車好,但是我們生產最多的,可能是腳踏車。人人都知道豪宅住起來舒服,但是普通人只能擠進
50個平方的經濟適用房。
無可否認,隨著經濟的發展,人們的生活水平會有所提高,正如硬體的發展,推動軟體的發展一樣。
東扯西扯,我想最主要的一點就是,不要什麼東西都絕對化,我們生活的社會就是一個很好的參考,不斷的學習,獨立的
思考,是應該做的事情。
當然,我發現在JAVA界,尤甚。
首先說說我為什麼會關心設計模式,最直接的是我聽說過這個東西,然後發覺這個東西確實為我的軟體開發工作
指了一條路,至少我發覺它可以開闊你的眼界。其次是我在開發工作中遇到了問題,由於缺乏設計,做成的軟體
擴充套件行和可維護性很差。舉個簡單的例子,我的一個專案中,由於資料層和表現層沒有很好的分離,後來軟體升
級,資料的組織形式和訪問機制已經改變,為了適應這個改變,很多東西需要重寫,包括展現層,而對於展現層,
其實並沒有多大的改變!我想如果我當初多點考慮軟體的設計,我想是可以把修改降到最低的。這只是一個簡單
的例子,實際開發中遇到的問題遠不止這些。
所以我開發關心設計,學習一些設計模式,嘗試把它應用到實際的開發中。但是讓我意想不到的是,在模式,OO
的運用上,存在這麼多的分歧,而且當我跟朋友討論起模式的時候,他正告我說小心走到模式的學院派裡。於是
我開始關注這個問題。
於是我嘗試問自己幾個問題:
1,模式是什麼東西,他可以給你帶來的是什麼。
2,應用模式到你的開發中,會有哪些負面的影響?
要回答這些問題,對於我現在的水平,顯然是不容易的。所以這裡寫的,只能算是記錄自己的心路歷程,而
並非經驗總結。
1,模式是什麼東西,他可以給你帶來的是什麼。
這個問題相信有參與討論的程式設計師都有自己的理解。我的理解是模式是特定場景下的特定問題的解決方法的指導。
離開了場景和問題,也沒有模式一說。這些指導方法哪裡來的,正確嗎?它來源於豐富程式開發經驗的程式設計師的
經驗總結。是的,它是一個經驗總結,是有經驗的程式設計師們總結出來的解決特定問題的方法,這些方法的好處一般
是提高模組複用性,減少模組間耦合,增強擴充套件性等。它給你帶來的最直接的就是提供給你一個解決特定問題的方法
,不是嗎?那麼你是否需要使用它呢?用不用,取決於你的判斷,你的問題和你的開發場景。首先你要判斷該模式是否
適用於你當前的問題,context和question是否一致,解決方法跟你的系統有沒有什麼衝突?在判斷為適用的情況下?
就是否需要用這個模式來解決這個問題呢?下面我們會分析這個問題。
2,應用模式到你的開發中,會有哪些負面的影響?
模式的缺點,一般都是由於它的優點所引起的,只所以成為模式,必有它的可取之處,我的理解是一般在提高模組復
用性,減少模組間耦合,增強擴充套件性等方面起積極作用。但是這樣的好處並不是免費獲得的,首先,從寫程式碼的角度來
說,你可能要寫花費更多的時間去實現,有些簡單的問題,或許你用過程化的解決方法,可以很快得到解決,但是運用
模式,你必須要分析你的應用場景,抽象你的問題,還需要理解你所使用的模式,掌握它,實現它。其次,由於模式一般
會在擴充套件行和複用性方面去考慮,程式碼的執行效率有時候就會必你直接的過程化實現要低,佔用的資源也可能會上漲。這個
你就要考慮你是否可以承受。
為什麼TCP的實現沒有用OO的方法,為什麼作業系統很少提供OO的API,為什麼CPU也只是一條條
的執行指令,而沒有提供更高的封裝模型?這些情況延續到今天。
500個平方的豪宅,旋轉式設計,當然你可以控制它的旋轉速度或者是否旋轉,智慧化的家居擺設,全可由遙控器控制,
智慧化的飛機起落平臺,不需要的時候可以智慧摺疊。。。。所有的東西,基本上都可以應需而變,只要你喜歡。
但是,如果你只是一個旅客,只需要在這裡住一晚,你是否樂意去住這樣一個豪宅,如果你只是一屆平民,口袋裡只
有百來塊錢,你是否認為這樣的房子有必要存在?更有甚者,如果我根本不懂什麼是高科技,而且我口袋裡根本沒錢,
難免我不會產生仇富思想,恨不得這個房子馬上跨掉。。。。
人人都知道高階豪華小車好,但是我們生產最多的,可能是腳踏車。人人都知道豪宅住起來舒服,但是普通人只能擠進
50個平方的經濟適用房。
無可否認,隨著經濟的發展,人們的生活水平會有所提高,正如硬體的發展,推動軟體的發展一樣。
東扯西扯,我想最主要的一點就是,不要什麼東西都絕對化,我們生活的社會就是一個很好的參考,不斷的學習,獨立的
思考,是應該做的事情。
相關文章
- 關於同步的一點思考-下
- 關於git flow的一點思考Git
- 關於難點的思考
- 關於社交圈子的一點思考
- 關於開發流的一點思考
- 關於網站設計的一點點討論網站
- 關於如何看原始碼的一點思考原始碼
- 關於黑暗力量(BlackEnergy)的一點思考
- [Android] 關於 Model 層的幾點思考(一)Android
- 關於 Method Swizzling 的一點思考
- Golang - 關於 proto 檔案的一點小思考Golang
- 關於大資料技術的一點思考大資料
- 關於寫技術部落格的一點思考
- 最近關於工作的幾點思考
- 關於json的幾點思考JSON
- 關於效率的一些思考:節點創新
- 關於物件導向程式設計的一點思考物件程式設計
- 關於程式設計師成長的一點思考程式設計師
- 關於工廠模式的一點個人看法模式
- 關於latch的一點點理解
- 關於《明日方舟》單局優點的一個思考
- 【odoo】關於odoo二開模組規範的一點思考Odoo
- 關於後臺系統自動生成的一點思考
- 關於程式設計師必備能力的一點思考程式設計師
- 關於網上各種技術文章的一點思考
- 關於Java併發多執行緒的一點思考Java執行緒
- 關於產品經理的幾點思考?
- 關於資料庫安全的五點思考資料庫
- 關於Decorator模式的幾點想法模式
- 關於PHP 的一點點小分享PHP
- 基於 GraphQL 實踐的一點思考
- 關於敏捷的一次內部爭論敏捷
- 關於提高程式碼可維護性的一點思考
- 關於設計業務應答狀態碼的一點思考
- CNNIC:關於移動社交應用”祕密”的一點思考CNN
- 關於語義化 HTML 以及前端架構的一點思考HTML前端架構
- 關於終端業務元件化的幾點思考元件化
- redo與undo的一點點思考