l

2016年8月10日 星期三

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

August 09 20:34~22:05

Typical_vb6_session

▲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。

沒有留言:

張貼留言