前兩天，我所在的項目有一個小的技術改動，打算把訪問Redis的密碼從數據庫挪到配置文件里。以前的代碼類似下面這樣：用戶第一次調用GetDatabase時，根據傳入的數據庫連接字符串訪問數據庫，從某個表里取出帶密碼的Redis連接字符串，然后建立Redis鏈接。至于替換成從配置文件中讀取地址和密碼，你可能10秒就想到了辦法，然后不到10分鐘就完成了下面的修改。完美，不是嗎？不但達到了目的，還刪除了一個無用的方法。但這是最佳的替換方式嗎？我是說，要想把某個實現替換成另一個實現，就應該這么直接上嗎？前兩天我在公司的小電風扇壞了，電源線和風扇接觸不良，只有在某一個特定位置才能通電。而我的一個同事的小風扇的電源是可插拔的，如果電源線壞了，換一根就是了。?我看到后驚呼：臥槽，接口隔離！！！對于系統容易發生變化（易壞也屬于變化）的部分，使用接口（電源線接頭）對其進行隔離，如果變化了（線壞了），就用其他實現了同樣接口的東西替換（即便沒壞，想換個顏色也是很方便的）。這樣的設計才叫設計啊。你也能看到，之前的實現和真正建立Redis連接的代碼耦合在一起。本來嘛，先構建一個ConfigurationOptions，再基于這個options建立連接，很自然的事情。但現在要替換的，其實就是這個構建ConfigurationOptions的實現方式。以前是基于DB，現在基于配置。一個實現要被替換，說明什么呢？說明這是代碼的一個變化方向。遇到變化的時候我們應該怎么處理呢？當然是創建一個接口來隔離這個變化。以前為什么沒有隔離而是耦合在一起呢？是因為沒有識別出這是一個變化方向。慢著，不要著急吐槽前人，犯這樣的錯誤其實是很正常的事情，甚至都不能稱其為一個錯誤。我們很難一開始就識別出業務或技術上的所有變化方向。但當變化真正出現的時候，也別急著著手修改。它以前不是一個變化方向，但現在是了。既然是了，就用接口隔離出來唄。好在代碼是可以隨時修改的，比電風扇強。我們重構最一開始的代碼，把構建ConfigurationOptions的代碼抽取出來。再把GetRedisConfigurationOptions方法抽取到新建的RedisConfigurationOptionsProvider類中。一開始的RedisCacheProvider類現在變成了下面這樣。這時候已經具備了抽取接口的條件。接下來我們為IRedisConfigurationOptionsProvider接口添加一個新的實現，基于配置來讀取Redis連接和密碼。再回到RedisCacheProvider類中，將接口的實現替換為ConfigBasedConfigurationOptionsProvider。再刪除舊的RedisConfigurationOptionsProvider類，大功告成。由于引入了修改的復雜度（抽取類、接口，引入新的實現），以前10分鐘能完成的工作，現在大概需要半個小時了。但這樣做的好處也顯而易見。我們識別出了一個新的代碼變化方向，并用接口對其進行了隔離。以后再發生變化，只需要提供一個新的實現就好了，也遵循了開放-封閉原則。你可能不覺得這樣做有什么好處，畢竟混在一起寫也沒有不會造成什么麻煩。的確這里的邏輯非常簡單，即使耦合在一起也沒什么大不了。但如果項目大了，很容易處處都是這樣的耦合。當一個類里出現多處這樣的耦合時，“發散式變化”的壞味道就出來了。如果你熟悉面向對象設計，可能已經脫口而出了，“這不就是抽象分支嗎？”。沒錯，是的。抽象分支就是替換一個實現的最佳實踐，小到一個類，大到一個基礎設施，都是如此。點擊閱讀原文，可以看到Martin Fowler關于抽象分支的文章。你是如何替換一個實現的？

總結

以上是生活随笔為你收集整理的如何优雅地替换一个实现的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。