AppLupus

設計原則1
找出應用中可能需要變化之處，把它們獨立出來，不要和那些不需要變化的代碼混在一起。

不管當初軟件設計得多好，一段時間后，總是需要成長與改變，否則軟件會死亡。

設計原則2
針對接口編程，而不是針對實現編程。

其真正意思是針對超類編程，不一定非要用接口，關鍵在多態。這樣程序在執行時會根據實際狀況執行到真正的行為，不會被綁死在超類型的的行為上。

更明確地說，是變量的聲明類型應該是超類型，通常是一個抽象類或者是一個接口，如此，只要是具體實現此超類型的類所產生的對象，都可以指定給這個變量。

設計原則3
多用組合，少用繼承。

組合建立的系統具有更大的彈性，不僅可以將算法封裝成類，更可以在運行時動態地改變行為。

1、策略模式（Strategy）
定義了算法族，分別封裝起來，讓它們之間可以相互替換，此模式讓算法的變化獨立于使用算法的客戶。

使用模式談論軟件系統，可以讓你保持在設計層次，不會被壓低到對象與類這種瑣碎的事情上面。

建立可維護的OO系統，要訣就在于隨時想到系統以后可能需要變化以及如何應付變化的原則。

2、觀察者模式（Observer）
定義了對象之間的一對多依賴，這樣一來，當一個對象改變狀態時，它的所有依賴者都會收到通知并自動更新。有push和pull兩種模式。

典型：Swing中的Listener。

設計原則4
為了交互對象之間的松耦合設計而努力。

關于java內置的觀察者模式支持。
Observable是一個類而不是接口，java不支持多繼承，限制了Observable的復用潛力，無法建立自己的實現。
它將關鍵的方法protected起來，這樣除非繼承自Observable，否則無法創建Observable實例并組合到自己的對象中來。
所以除非Observable符合你的要求，否則自己實現一套觀察者模式。
setChanged()方法把changed標志設為true，notifyObservers()只會在changed標為true時才會通知觀察者。

不要依賴于觀察者被通知的順序。

設計原則5-開放關閉原則
類應該對擴展開放，對修改關閉。
---代碼應該如同晚霞中的蓮花一樣地關閉（免于改變），如同晨曦中的蓮花一樣地開放（能夠擴展）。

讓設計的每個部分都遵循開放-關閉原則，通常是辦不到的。即使做到了也會耗費大量的時間和精力，遵循開放關閉原則通常會引入新的抽象層次，增加代碼的復雜度。你需要把注意力集中在設計中最有可能改變的地方，然后應用開放-關閉原則。
這需要多看例子積累經驗。


3.裝飾者模式（Decorator）
動態地將責任附加到對象上。若需要擴展功能，裝飾者提供了比繼承更有彈性的替代方案。符合開閉原則！

裝飾者與被裝飾對象擁有相同的超類型。
可以用一個或者多個裝飾者包裝一個對象。
在任何需要被包裝對象的場合，都可以用裝飾過它的對象代替它。
裝飾者可以在被裝飾者的行為之前/之后，加上自己的行為，以達到特定的目的。
對象可以在任何時候被裝飾，所以可以在運行時動態地、不限量地用你喜歡的裝飾者來裝飾對象。

典型：java i/o 。FilterInputStream就是一個裝飾者類。

“缺點”：利用裝飾者模式常常造成設計中有大量的小類，數量實在太多了，可能造成使用此API程序員的困擾。但是，當了解到裝飾者的工作原理，以后使用別人大量裝飾的API時，就可以很容易地辨別出它們的裝飾者類是如何組織的，以方便包裝方式取得想要的行為。

初次接觸java i/o類庫，往往無法輕易理解它。但是一旦認識到這些類都是用來包裝InputStream的，一切都變得簡單多了。


4.工廠模式（Simple Factory）

把new操作符替換成工廠對象的創建方法，不再具體實例化。

把產生對象的代碼分離出來，這樣其余的代碼沒有和具體的對象打交道，就可以對修改關閉了。而獨立出來生產對象的工廠可以為很多的類服務！不僅僅是剛才那個。

工廠方法用來處理對象的創建，并將這樣的行為封裝在子類中。這樣，客戶程序中關于超類的代碼就和子類對象創建代碼解耦了。