D13 令人感到麻煩的設計(1)──Data Model的設計

直覺地把系統的動作寫成程式是最快的開發方式，在執行上也很可能比較快。設計雖然也同樣地把同樣的系統動作寫為程式，但是多了很多與處理層次有關的類別，不僅在開發上相對緩慢，執行上也會因為呼叫的路徑變長而變慢些。

想像一下，我們是印表機延伸工具的開發廠商。依前面所談的，公司已經準備好Base Model作為基本資料類別，現在第一版系統要支援三款印表機。在一開始的Data Model設計有人提出了像上圖的方案，身為Leader的你應該通過這個Data Model設計嗎？

這個設計基本上當然可以讓系統正常執行（就算只用Basic Model也可以，但那會一團亂），然而設計的目標是讓系統的程式分門別類地形成層次。這裡的問題在於印表機延伸工具的系統，會定義出一些自己專用的資料與存取方法，以這個設計來看，那些專用的方法都必須實作在三組Data Model裡，不管是個別使用的或者是三種用法都相同的。

如果我們曉得要把重覆使用的程式區段抽取為方法來使用是正確的方式，那麼把重覆使用的方法再抽取到一個類別來reuse也是應該做的事情。雖然設計因此多加了一個層次，但是每個物件各司其職不作重覆的事，是OOAD所要表達的一個重要精神。