程序設計模式淺析（plain framework商業版設計模式）

時間 2019-11-19

標籤程序設計模式淺析 plain framework 商業設計欄目軟件設計简体版

原文原文鏈接

程序設計其實對程序開發者來講十分重要，可是在工做中每每咱們卻忽略了這一塊，由於咱們所用的都是現有的模式。一個設計模式的好壞，每每可以體現出程序的專業性，還有整個項目的可持續性。這就是爲何有些公司，在經歷了若干年後突然重寫整套代碼的緣由，由於他們會發如今愈來愈多的需求的狀況下，之前那些設計模式徹底不能知足了，或者說程序的複雜度和維護成本實在過高。最近我又看到了一個公司的項目設計，文檔中寫的還算優秀，但是總體的框架設計總以爲還有差強人意。那麼咱們又該怎樣來設計咱們的程序，怎麼減小維護代碼的成本，怎樣使框架可以知足不斷增添的新需求或技術？設計模式是一個老生常談的問題，並且有些技術員將其神乎其能，做爲一個出來也有幾年的人來講，我也很感謝網絡上許多朋友無私的知識分享，因此基於plainframe work（簡稱PF）的開源精神，就算是作成了商業版，我也將對接下來的設計模式徹底公開的分享給你們。html

什麼是設計模式？

　　設計模式（Design pattern）是一套被反覆使用、多數人知曉的、通過分類編目的、代碼設計經驗的總結。使用設計模式是爲了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。毫無疑問，設計模式於己於他人於系統都是多贏的；設計模式使代碼編制真正工程化；設計模式是軟件工程的基石脈絡，如同大廈的結構同樣。（這段來自百度百科）
　　一句話設計模式的產生和應用主要是方便代碼的管理，以及節省維護的複雜成本。git

現有的模式

　　最近進入一家公司，該公司主要進行頁遊方面的開發，聽說有一款比較不錯的產品。抱着去學習的心態，那是由於本身以爲技術還要須要不斷的提升，還有就是別人的成功是否和技術有着直接的關係。由於來的日子並不太長，因此只能簡單看到一些腳本層的東西，其腳本也就是你們所熟知的lua了。只不過在腳本層，他們進行了一些簡單的封裝，如本身寫的加載文件的接口等。不過他們彷佛很聰明的把lua的擴展名改成.txt，這麼別人一眼就不能看出這是一個lua腳本了。其次再看腳本的結構，我只是粗略的看了下，分爲幾個目錄場景、配置目錄、方法目錄。乍看之下，目錄層次仍是比較分明的，但是若是要找尋某個系統對於剛看不到一天的我來講仍是以爲十分吃力。一是服務端沒有詳細的目錄介紹，彷佛你們的開發很隨意，那個模塊須要你十分熟悉了才能找獲得。二是腳本調用結構不分明，調用C++和自身的一些方法沒有必定的區分。最後說一點的就是，若是你須要找尋某個功能就須要問熟悉的同事，或者你須要將裏面的代碼從新梳理一次不可，並且註釋極少，你很難看到那裏是真正你應該去修改或是增長。看了這些後，對於賺錢的項目就有好的技術，我一會兒就完全的明瞭了。
　　鑑於上面的緣由，不少的開發者才那麼以爲應該進入技術較好的公司，諸如網易騰訊之流來提高本身。並且從這些公司流傳出來的代碼，可謂成爲你們手頭上以爲十分厲害的香餑餑。其實麻煩是本身形成的，若是你們懂得合理運用比較好的設計模式，那麼你也沒必要去羨慕那些技術很牛的公司或是人。做爲一個開發者，你們並無太大的區別，並且技術又是在天天在進步，舊的技術極可能會在下一刻更換，那麼這個時候人人的機會都是平等的。
　　一種好的開發模式，必然會對從此的發展有着很大的幫助，若是你想要達到更高的層次的話，對於一名開發者，你就須要全面的去了解設計模式。如今市面上用的比較多的是工廠模式以及MVC的思想，工廠模式這是一個很古老的東西，在這裏就不詳談了。而之因此將MVC稱之爲思想，那是由於早先這個模式是用在網頁開發上的，特別是在一些大型語言JSP、.NET.ASP、PHP上。簡單說一下在網頁設計的三個東西：數據的處理（MODULE）、邏輯的處理（CONTROL）、界面的顯示（VIEW），在WEB開發中一開始人們幾乎是將這三者糅合在一塊兒來作的，這樣代碼的可讀性和重用性很是之很差。因此有人就這樣將各自的分工獨立開來作，就像早期的資本主義裏的公司體系同樣，沒有統一的管理，分工很是不明確，效率很是之低。在網頁中數據的處理通常指的是讀寫數據庫的操做，邏輯的處理主要處理從用戶操做所返回的一個系統的請求，好比說登錄這些，須要處理驗證密碼、處理註冊這些操做，而界面的顯示主要負責客戶端界面上能夠直接看到的東西。
　　MVC的思想如今已經普遍的用在了各類設計上，包括在客戶端也會用到這個思想，只不過數據的處理這塊變成了內存的讀寫而已。不過對於MVC我的的理解是，它充分體現了面向對象的設計，更趨於人性化的管理。github

　　MVC基本的思想：數據庫

　　除了工廠模式和MVC的思想，其實現有的模式還有不少，我在這裏就不一一舉例了。設計模式

咱們須要一點改變　　

　　任何設計模式都有其侷限性，這裏稱之爲改變的，實際上是指不要生搬硬套模式的思想。在設計的過程當中，咱們每每要這樣想：這樣設計可行嗎？這樣設計複雜嗎？這樣設計有沒有後遺症？
　　弄清了三面的幾個問題後，咱們再來講目錄結構的設計，目錄結構儘可能的井井有條，可是目錄嵌套的層數儘量的少，最好的設計目錄的嵌套最好很差超過五級目錄。由於太多的嵌套，會將整個目錄看起來比較複雜，有的時候咱們寧肯使用文件前加前綴來作，如opencode_style.h、opencode_view.h這樣，而不是將其分紅目錄（當前其前提是目錄層級已是第五層了）。
　　再來咱們說說接口的設計，接口的設計看起來簡單，由於他用不着關心怎麼實現，但是從深一層來講，接口設計其實並不簡單。在一些比較大型的企業裏，接口的設計並非通常程序能夠隨便能接觸的，而是由專人去負責這個東西，並且這樣的人，在公司內來講是有必定的技術的（稱之爲大牛）。接口設計的重要性，主要是它是否是更靈活，是否是能夠方便的擴展，是否是有更好的複用性？若是一個接口都同時知足了這三點，那麼這樣的接口算是比較好的了。用通俗的話來講，接口主要是看可否在之後可以繼續使用，就算出現了新的技術，這個接口是否能夠靈活的適應。
　　最後說一下具體的代碼設計，儘可能將邏輯的處理與數據分離，儘可能將消息的處理單獨的放到一個地方統一進行。網絡