代碼隨想

        今天在寫軟件的播放器模塊的時候對自己寫的幾個類之間的關係以及每個類所做的功能感覺不是很滿意。管理類做了太多的細節, 被管理類卻做了許多專注功能之外的事情。停下來仔細想了下如何設計一個類。

        類的設計過程就是對軟件工程的功能解析的過程。我覺得這個軟件功能解析的時候可以不用考慮管理類,或者說不用考慮類與類的層級關係。現在有如下疑問:

        1、 如何確定一個類?

        2、 一個類的功能到底是什麼?

        3、 管理類的作用是什麼?

        4、 如何控制類的層級關係?


要解決以上問題,首先我們要解決下面幾個問題:1、你的這個模塊(假設你負責了一個模塊)要完成什麼樣的結果? 2、 你的這個模塊需要什麼樣的數據來源?


大致我提出了以上幾個問題,現在說說我的個人想法:

        首先,模塊需要完成什麼樣的功能需要什麼樣的結果?比如說,我要寫一個功能模塊是播放音樂(網絡和本地),這就是我要的結果,我需要這個模塊能播放兩種來源的音樂。只有確定了你的模塊的具體功能你才能去設計這個模塊的其他東西,這是個大前提。無論你做什麼都是這樣,不僅僅適用與功能模塊的編寫,也適用於整個軟件的設計。明白你想要造出的東西要實現什麼樣的功能是每個設計過程中要時刻提醒自己的東西。

        其次,當你明白了你要做什麼之後,那麼是該思考怎麼做的時候了。這個時候要抓住最重要的東西,就是已知條件,你的模塊所作的所有工作都是在對一個已經知道的條件進行的反覆,層級式,分解式等的加工。再次強調,已知條件!請跟我說已知條件!還是你知道你的已知條件麼?好吧,我承認我又說了一遍已知條件。對,已知條件就是傳進你的模塊最原始的數據!最原始的數據啊!你聽懂了麼!!!最原始的數據啊!程序員的價值就是把最原始的數據加工出花樣來啊,想想你要用最原始的數據通過堆,棧,隊列,樹,各種各樣的算法,讓這個最原始數據在不同的時間(數據流動到某個類的那個時間點,你可以這樣想)和空間(數據此刻所在的那個類,你應該這樣想)展現出不同的形式。這就是祖先啊!最原始的數據!如果你在寫一個模塊的時候不知道你的功能模塊要完成什麼功能,我覺得你可以去死了!如果你不知道你功能模塊的最原始數據是什麼,我覺得你可以下地獄了!

        好吧,這個時候我想下一步就是我完成了功能模塊要求的功能,那麼我該提供怎樣的數據給外部呢...功能完成了,有的時候需要提供數據,有的時候不需要提供數據,這個就看外部對模塊的要求了。

       記住設計的時候一定要抓住兩點,給我什麼東西讓我去做什麼然後需要返回什麼樣的結果?(鐵律,一定要形成這種思想,我發現以前沒有總結的時候自己也是這麼做的,只是今天想想反而加深了自己的這種思考設計的認識)

        上面的2個問題說完之後,基本的指導思想就有了。上面的指導思想是放之四海而皆準的,無論你是設計整個軟件,無論你是設計一個模塊,還是小到你設計一個類,一個函數都是應該以上面兩個問題的結果作爲指導思想。

        開始解答上面幾個疑問:

        首先是如何設計一個類:這裏書上說了幾個原則,什麼開閉原則,最小功能原則,什麼抽象接口啥的等等。我覺得一大堆東西,只要把握住最京哈的幾點:足夠小而又不散,足夠的專而又不刻意獨立,然後就是把握住不要依賴。其實這個東西很需要經驗,我感覺自己寫了這麼多代碼還是不夠。只能先講下我的理解了。小而不散:我的理解是類不要龐大,龐大了,你的類職責大多數都不是單一職責,你見過一個人佔得空間比兩個人大麼?(特殊情況除外)。散就是把本來應該在一起的東西爲了追求類的小而拆成幾個類,你能把胳膊和大腿拆開不當四肢麼?其實最重要的我認爲還是第二點,類的功能要專一,這個纔是一個類設計的精髓所在!專一就是好啊!一個類只做一件事,這個關鍵就是我們要把功能抽象好,然後把這個功能賦予給這個類。讓這個類單一的來完成。所以,第一問題我的最終答案應該是:專一的類,默默的只做一件事兒的類就是個好類。

       其次是一個類的功能到底是什麼?有的時候很迷惑,其實弄清楚這個問題,我想就不存在其他任何問題了,功能都弄懂了,那就剩下體力活了。我想講講我現在對類功能的劃分。排除其他干擾因素,我們只說類的功能。我把類分爲:管理類,功能類,輔助類。我覺得這個分法應該能夠把類的主要功能分清楚了。管理類顧名思義就是管理其他的類,讓其他的類協同工作來完成一個具體的功能,說白了就是對數據的一次具體加工,入口是管理類,出口還是管理類,完成處理的就是功能類。你可能會說我爲啥滅有提到我分的輔助類。是的,它就是個輔助性的功能,比如說我一個管理類要完成對數據的存儲,然後我需要給每個文件編號,那麼我可以寫個類作爲管理類的輔助類,他的功能是生成一個不重複的編號。這就是輔助類,其實在錯綜複雜的類關係中,你如何能夠從類中找到輔助類纔是真正的王道。爲啥我這樣說...你可能會說輔助類又不是功能類,但是我要說你如果能夠把輔助類找出來,那麼你的整個模塊的架構基本就清晰了,因爲輔助類讓類於類之間的關係變得複雜,你可以認爲輔助類就是早晨的迷霧,遮蓋了山道,讓你找不到上山的路,迷失在茫茫大山中。

        上面說到類的分解,接着就是管理類到底做了神馬?很容易知道的兩點就是它維護了數據的出口和數據的入口。其實這個說法並不準確。因爲無論是你傳過來需要加工的數據源還是從外界傳進來的一個狀態變量都可以成爲數據進入。我覺得準確的說容易的兩點是它維護了“核心數據”的出入口。什麼是核心數據?就是我其他類需要加工的數據,需要把它打扮的花枝招展,不同形式展現的數據。就是至始至終從入到出都是一份數據(只是不同的結果罷了)。那麼管理類還維護了什麼呢?我覺得這個纔是真正的重點。狀態!請大家跟我喊,狀態!狀態!狀態!有些程序員經常說,媽的查了半天的bug,原來是個bool值應該傳進來的是false,我傳個true,又或者,我的天爺爺,這個bug竟然是我忘了處理網絡改變引起的變化,這個管理類應該加個網絡改變的變量,有網絡就播放網絡歌曲,沒有網絡就停止播放,不能卡死在哪裏。答案已經出來了。一個管理類維護了外界傳進來需要加工的數據和外界傳進來控制加工的數據。我把他們成爲基礎數據流和控制數據流。基礎數據流是讓你去處理完成你的模塊具有的功能的,控制數據流是告訴你怎麼處理這個基礎數據流的。管理類維護了一個控制流的中的狀態,把這個指令下達給它的“小弟”們,小弟們根據這個狀態去完成工作。很像公司的管理不是麼?

        說了這麼多,其實最後一個問題的答案應該就是設計中的技巧了,你運用模式,繼承,多態,代理等等方式來劃分整個模塊的結構,這個時候你也賦予了你的程序以生命力,複雜關係就是這樣形成的。

       現在只能思考到這些,暫且記錄下來,備案...希望自己的設計能力能一步步提升...

        下班,回家...

        生活其實就是一個程序...很大的程序,完美的程序...




        


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章