我覺得是沒辦法，雖然我不會因為 framework 的原故讓 simple design 轉彎，但仍有些因素會影響我的設計。例如:

Performance，其實我看重這個過於程式可讀性。

不得不用別人寫好的 utility 時。我會讓程式呼叫方式和該 utility 相像一點，避免複雜的轉包。

為什麼 framework 不能改變設計但 utility 卻可以呢? 因為 framework 是可以不用的。但有些 utility 卻是不能不用的。如 lucene, quartz。

不得已的情形總是得轉彎。但是很多情況不是不得已，而是自己討皮痛，或是崇拜名牌，刻意找重型Framework來整自己。

要不要複雜轉包，決定於問題的複雜度。例如依照Lucene文件相關度做自動分類，就可以用mock的similarity rating，在test case自己餵值。因為自動分類的重點在於相關度和類別，不需要做出真的文件，也不需要讓Lucene算相關性。

因為自動分類還蠻複雜的。

我講一個我覺得不想轉包的例子，例如，我們要抓取所有某個網站的網頁，純粹依功能設計，我會把 WebFetcher 寫成 iterator。

但若我們用的工具是要你給它一個 callback 來儲存網頁，然後它幫你做到底，我就不會轉成 iterator。如果做多餘的轉包，或許對呼叫者更便利，但是當抽象層漏水的時候接手者更累。

自動分類一定會有轉包的。

另一個不想轉包的例子，因為用了 quartz。所以在 ScheduleService.listAll() 直接傳回 quartz 的 Trigger 物件而非轉包過的 class。這點可能見人見智。

除了抽象層漏水以外，轉包層本身就是增加複雜度。的確是要權量厲害得失。我有時包完後悔又拆了。