注重原則和智慧結晶——讀《浮現式設計》有感

        題記：正在讀《浮現式設計:專業軟體開發的演化本質》(榮獲第19屆Jolt生產力大獎)一書，順手寫下了一點自己的感想與淺見，是以為記。

 

        使用與建立分離原則是我以前沒有接觸的，說起來很易於理解，即分離對象的建立和使用職責，在一個系統中，限制任意實體A與任意實體B之間的關係，A可以建立B，或者A可以使用B，但A不能既建立又使用B。通過這樣的分離，使得建立和使用被獨立開了，如果建立方式發生變化，那麼不會影響到使用方；如果使用方式發生變化，也不會影響到建立過程。

        比如有如下的類：

        工作管理員通過任務調試器來完成一些事情，二者是獨立的，有各自的生命週期，如果中所示來編碼，則會讓工作管理員承擔任務調試器的生命週期維護工作，同時也讓工作管理員與具體的任務調度器類型增加耦合，沒有充分發揮物件導向的多態特性。

        如果改成：

Void doSomething(TaskScheduler scheduler){    Scheduler.shcedule();}

        則一方面工作管理員不用增加額外的對調度器的管理職責，另一方面也與具體的調度器類型進行瞭解耦，從而不關心調度器的建立過程，是一種建立與使用分離原則的體現。

        那麼建立工作去哪了呢，當然我們有很多的方式可以解決對象建立的問題，原廠模式也好，靜態方法也好，建立的職責集中在一起，也可以利於條件建立或從外部屬性動態決定建立類型。

        不過我想，這個原則不應該到處都用，畢竟一個軟體中有太多如所示的用法了，如果都這樣進行建立與使用分離，會引入非常多的工廠類或Factory 方法，反而會把代碼結構搞得更複雜。其實根本上來說，是否採用這種方式，還是取決於這樣做所能帶來的價值。設計人員要對建立的可變性進行一些分析和設計工作，如果建立是不可變的，那就不用捨近求遠了，原則是指導，但什麼時候要應用，還是取決於應用後能否帶來更大的價值。

        對於開閉原則，依賴倒置原則以及Gof提出的面向介面設計、優先使用組合而非繼承等原則，有太多的書籍在說，就不再重複了。

        總之，原則和智慧能帶給我們很多協助，在總體上給予指導，但最終還是要看實踐，要在具體的環境中做出取捨和平衡。

——歡迎轉載，請註明出處 http://blog.csdn.net/caowenbin ——