復制和粘帖是封裝的大敵
2024-08-30 08:34:05
供稿：網友
在侃侃而談OO，侃侃而談設計模式，侃侃而談面向對象的諸多原則之前，我們首先應該掌握一點：封裝。掌握好封裝的原則和技巧之后，就算使用的不是OO語言，也能構造出框架優美的程序。將這些原則用在程序之外，也能得到出奇的效果?！对O計規則-模塊化的力量》(http://www.douban.com/subject/1737636/)將封裝與模塊化放在神壇的高位，它們配得上這個位置。這是我們解決復雜性問題的最基本的方法（沒有之一）。
程序是一種復雜性系統。“道生一，一生二，二生三，三生（四，四生…）萬物”。若將復雜性的根源當作“道”的化，那么這個“一”必然是封裝。不同的程序語言以及由這些程序語言衍生的方法，則處于“二”的地位，比如 OO 設計范式、FP（函數編程）范式、分層的原則等等。OO設計準則，什么里氏替換原則，什么組合優先于繼承，這些處于“三”的地位，具體的設計模式什么之類的處于“三”之后“四”的地位。
本人愚笨，至今尚記不清那些原則，如里氏替換原則是什么，那些這個模式那個模式怎么實現。設計模式中，俺只對策略模式感興趣，對其它模式興趣索然。實質上這些模式也好、準則也好，只是給我們提供了一種方法、一種工具去更好的實現封裝。
復制和粘帖是封裝的大敵，是丑陋代碼的最大的壞味道。復制一份，就相當于增加了至少一個可變點，復制兩份就相當于增加了至少兩個可變點。為什么說“ 至少”呢，因為模塊之間存在關聯關系，導致一個地方的變化會導致其它的多個地方也必須隨之變化。如果假定S為系統本身，M為對系統本身的一個測量，C為系統S中模塊的平均復制份數(C>1)，則這個M與C的關系應該是一個指數的關系: M正比于C的N次方(N>1)。
指數關系已經很可怕了，更可怕的是，當系統中的模塊出現變化時，如果該模塊在系統中有多個副本，我們可能偷懶，只改變了其中的一個副本，而不是全部副本都進行修改，這樣就導致模塊的分裂，由一個模塊分裂成幾個類似而又不同的模塊，大大的增加系統的復雜度，最終導致系統的腐爛。直覺上，一個設計很爛的系統，它的復雜度大致是模塊數量的階乘關系甚至是冪指關系，這是比指數關系更恐怖的關系。
所以，復制和粘帖是一種非常邪惡的編碼方式。在編碼時，需要千方百計的去想辦法減少復制和粘帖。這是在編碼時就應該注意的問題，而不是放在重構階段去做的事情。至于使用什么方法，使用什么手段，使用什么模式則是細節問題。
堅持不復制和粘帖，堅持下來，收益會非常大，寫出來的代碼質量高、含金量高。看見別人的系統，能馬上分辨出這個系統的優點是什么，缺點是什么。什么設計模式也好，接口的正交性也好，設計原則也好，也許你從沒刻意的去學過，卻最終發現殊途同歸，冥冥之中與國外大牛有一種心意相通的感覺。會自發的去組合、去改良這些大牛們的思想和方法，甚至去創造新方法新手段。直接由一入手，一生二，二生三生四，而非教條的、頂禮膜拜的去學這個三，學這個四?；蛟S那個時候，你已經忘記什么是對象了。
之所以發這些牢騷，是因為昨天至今天，正在重構一個模塊。這個模塊M1的核心部件是一個包裝自RTF的layout規則編輯器。設計這個核心部件的哥們以RichTextBox為中心設計了一個控件A，然后將這個控件的部分規則邏輯抽出來放在類B和類C的靜態方法之中，更神奇的是這個類B是在另一個模塊M2之中，類C倒是在模塊M1之中。這個控件在M1中被三個地方給用到：D、E、F，這D、E、F每個地方都要為這個空間A注冊七八個事件，然后在事件的回調函數中調用模塊M2中的類B的靜態方法及模塊M1中的類C的靜態方法去實現一些邏輯?，F在呢，我要寫一個控件G，這個G也要用到控件A，在這種情況下，我必需為G注冊一堆A的事件及回調函數，然后在回調函數中弄一堆邏輯，至少得200行代碼。為了寫這些回調函數，我必須得搞清這個A控件及類B，類 C的內部運行機制。也就是說，為了吃豬肉必須得親自去殺豬。當然，也可以從D、E或F 中Copy代碼過來改吧改吧來節省時間。
問題嚴重的地方在于，這個控件A本身存在邏輯錯誤，存在功能不完善的地方，需要對它動手術。因為到處復制，牽一發而動全身，給A動手術必須也要給 B、C、D、E、F五個類動手術。在給A動手術時，為了編譯通過，我將B、C、D、E、F中與A相關的代碼全給注釋掉了，前后注釋了1500行代碼左右。實質上這1500行代碼真正有價值的代碼也就在200行左右，其它的代碼全是復制、粘帖，然后改改變量名完成的。
為什么會出現這樣的問題呢？因為復制和粘帖。復制和粘帖省事啊，Copy過去改幾個詞就能用了，不用花費心思的去想封裝。而實際情況是，要引用那個控件A，得寫200-300行代碼，多引用幾處，就得寫1000多行代碼，復制和粘帖的話倒不費事，但如果發現這個A存在錯誤，或者需要擴展，在改A的同時，同時也要動這1000多行代碼，這1000多行代碼中可能會牽扯到更多的代碼，最終導致必須修改更多的代碼，這便是代碼的腐爛。
其實這個A是很好封裝的，它不需要其它的類對它輸入任何輸入數據，其它的類只需要從A控件中獲得一個最終的規則結果，一個List。封裝的好的話，調用A，獲得結果，兩三句代碼就可以實現。
之所以不封裝是因為習慣了復制和粘帖，或者懶于去封裝，或者頭腦中根本沒封裝這根弦。
很多新程序員或者不新的程序員，尤其是Web開發程序員老抱怨工作的技術含量低，老是想學更多的東西。實質上，他們所作的工作是非常有技術含量的東西，就看怎么看待。
如果只將自己的工作看作簡單的復制、粘帖、抄襲、改代碼的話，自然技術含量低了。如果將自己的工作看作如何消除復制和粘帖、如何提高質量、進度，消除工作中的不必要事情，消除各種浪費，那么這個工作的技術含量是極其高的。不要膜拜大師，當你這么做的時候，你做的正是大師的工作。不要膜拜新技術，當你這么做的時候，你的工作可能正是新新一代技術的萌芽。一點一滴、一色一香，全在心中。青青翠竹、盡是法身，郁郁黃花、無非般若。
