不要為復用而設計

本文的作者Elliotte是一位著名的IT方面的作家，寫20多本關于編程方面的書籍，有很多書籍在國內都有出版，其中包括《重構HTML:改善Web應用的設計》， 《Java I/O》， 《Java網絡編程》，《Xml Bible》和《XML in a Nutshell》等，目前他正在研究XML處理器XOM、jaxen XPath引擎和Amateur媒體播放器。

上周，一位同事的一個觀點讓我深受啟發，這個觀點是如此的顯而易見，以至于當他說出來時我驚奇于為什么以前沒有意識到這點：

如果你為復用而設計，那你就做錯了。

你現在要寫的代碼的唯一目的就是服務于你目前手頭上的需要解決的任務。不要為復用而設計。不要去考慮復用。不要為讓代碼復用而浪費一秒鐘時間。

事實上，任何你需要的可以復用的代碼都已經存在了。想要去連接一個HTTP Server，并且要全面支持安全認證和cookies嗎？這個東西聽起來很多項目都可以用到，于是，你想把這個東西封裝一下做成一個易用的HTTP類或共享包，很好的想法不是？錯。你應該使用 Apache HttpClient。

需要解決你的拋物線方法的初始值問題嗎？不要去翻看你的《numerical analysis textbook》，你需要做的是下載Flanagan的Java科學計算庫，或購買一個NAG許可證。想要給你的同事們做一個日歷選擇組件嗎？直接告訴他們去用JCalendar。盡管它在外觀和使用方法上和你想象的不是完全一致，但完全夠用。如果你打算做出自己的組件，或找一個現有的修改一下，你會發現，你開發出的這種不一樣的表現效果并不適合另外一些人的應用，所以，不要浪費時間去開發自己的可復用的代碼。

這些例子都是針對Java來說的，但對于另外一些主流的語言，比如Perl，Python，Ruby，C++，C#，Scala等，都是適用的。事實上，如果一種語言不能提供解決你的問題的可復用的代碼，那你就是選錯了解決你的問題的語言。

有例外的情況嗎？我只能想出兩種(目前為止我感覺沒有第三種情況了)。

第一種例外是你在開發一種新的東西，你需要的類庫不存在，你是第一個進入這個領域的人，你需要寫出可復用的代碼。例如，當我率先開發出XIncluder類庫時，XInclude的規范還處于制訂中，你在Java里找不到第二個可用的類庫。我寫的這個類庫成了規范的可實現的一種證明，推動了規范向更完備的狀態發展。十年前開發我自己的XInclude類庫是明智的，而今天絕對不會再重做這樣的事。

第二種例外情況是針對專家的，我甚至還不確定這是否是例外。如果你是某一個領域的真正專家，有可復用的代碼能解決你的領域的問題，而你經過認真的研 究現有的解決方案，你認為它們是不完善的，你在尋找一種更好的解決方法，這時，而且只有這時，你可以考慮寫出你自己可復用的代碼。這就是我為什么要開發XOM的原因。只是在我寫了數百頁的書稿，詳盡的收集了目前Java里處理XML的各種API，知道了它們的優點和缺點后，我才覺得應該坐下來設計一個API來改進它們。盡管我認為我設計的API是最好的API，但我仍然不確定把時間花在它上面是否值得。XOM，按我的觀點，比之前的任何API都好，但它并不是好 到能夠在大量的其它項目中替代其它的類庫。對這個新API的需求不是真正的很大。

還有另外的例外嗎？還有另外的一種情況里你需要寫出可復用的代碼嗎？我想不出。有如此多的程序員花了如此多的時間來探索我們生活中存在的問題，并把 他們的成果放在 Sourceforge 和 Github 這樣的網站上免費分享。當然，新的問題會不斷的出現，但對一些老的問題，如果去再重新研究它們一遍，你并不能從中獲得多大的收益。下一次，如果你發現自己 在為復用而設計，請住手，問問自己是否可以復用別人的代碼。

[英文原文：Don’t Design for Reuse ]