好技術不死，只是換個名稱再來一次

August 09 20:34~22:05

▲VB 6.0經典畫面，圖片來源自維基百科

 

最近打算用運用Microservices + Domain-Driven Design + User Story Mapping + DevOps技術去重構（再造？）一個持續開發了好幾年的既有Web-based系統，事前的準備工作花了很多時間在閱讀相關資料。今天在《Implementing Domain-Driven Design》書中看到一段對於Anemia Domain Model（貧血領域模型，只有getter、setter而沒有商業邏輯的物件）的說明讓Teddy想起一段往事。

書中提到造成Anemia Domain Model的原因可能來自於照抄不良的程式範例，以及Visual Basic（VB）所產生的歷史影響。話說當年的VB的IDE環境可以用拖拉圖形介面元件的方式快速開發出跑在Windows上的程式。開發人員只要設定一下圖形介面元件的屬性，並在元件上點兩下直接撰寫事件處理程式即可輕輕鬆鬆完成一隻Windows應用程式。

後來Java流行之後也想要如法炮製VB的成功經驗，於是定義了JavaBean標準。JavaBean就把VB介面元件的「壞習慣」帶到世界各地，加速Anemia Domain Model的應用。

***

在VB流行的時代（不是現在的VB.NET）Teddy也用VB寫了一堆商業應用程式，甚至在服兵役期間有一整年都用VB在寫程式，退伍之後還繼續寫了幾年，直到後來完全改用Java。VB雖然方便，但因為不支援實作繼承（implementation inheritance）只有介面繼承（interface inheritance），這樣要怎麼做到程式碼重用（code reuse）？當年一直覺得VB開發環境很好但語言本身有點遜遜的，遠比不上C++來得酷炫。

後來有一天讀到GoF的《Design Patterns》，書中第一章有兩句至理名言：

• Programming to an Interface, not an Implementation
• Favor object composition over class inheritance

第一句話比較沒什麼，但是第二句…蛤，蝦米，居然要多用物件複合（object composition）少用類別繼承（class inheritance）？！這麼說起來VB根本不讓你用類別繼承那不是好棒棒？放下內心對VB的「歧視」，加上GoF設計模式的加持，後來用VB開發的幾個系統大量透過介面繼承和抽像耦合來實作design pattern，程式碼不但精簡許多，擴充與維護性也改善很多。雖然有時候缺少類別繼承還是有點不方便，但比起之前只是用程序導向的方式來使用VB，工作效率已經改善了不知多少倍。

後來從VB轉到Java，因為之前學過C++又用過VB的介面繼承，轉換過程輕鬆許多。對於Java區分類別繼承與介面繼承的「苦心」與應用方式完全可以理解。

***

俗話說：「凡走過必留下痕跡。」VB語言雖然不完美，但用到極致還是可以開發出模組化與可擴充的軟體系統。投資在「舊技術」的時間並沒有浪費，在VB上套用的物件導向設計和錯誤處理經驗後來在開發Java應用程式，以及更久之後念博士班做例外處理設計研究都派上用場。

這幾天在研究DDD，手邊的書加起來超過1,500頁，怎麼在1週內抓出重點然後直接套用在專案上？還好讀了之後發現原來Eric Evans的《Domain-Driven Design》是仿照建築師Christopher Alexander的《A Pattern Language》做法，提出一套領域驅動設計的模式語言（pattern langauge）。而領域驅動設計方法又可以和敏捷方法、BDD/TDD以及軟體架構密切結合。因為對於這些方法都很熟悉，所以看起書來可達事半功倍之效。

很多技術並沒有死亡，只是換個名稱、換個身段，再上台一次。

***

友藏內心獨白： Favor knowledge reuse over code reuse。