各種設(shè)計模式--應用場景：
裝飾器模式：
1、類繼承會導致類的膨脹，這時候裝飾器就派上用場了
責任鏈模式：
1、ifelse 用責任鏈來實現(xiàn)
狀態(tài)模式：
1、ifelse
適配器模式：目的是在原來代碼的基礎(chǔ)上面，增加一些修飾的東西。
1、訂單信息，比如增加了活動了之后，返回結(jié)果中要包含活動信息，在原來代碼的基礎(chǔ)上面給返回的Bean里面增加一些活動信息。
代理模式：
比如吧，我有一個業(yè)務，同時要調(diào)用外部系統(tǒng)的http實現(xiàn)的接口和webservice實現(xiàn)的接口，可以做一個代理類， 代理webservice接口和http接口， 代理類幫我判斷該用哪個， 我直接調(diào)用代理類就行了。代理類專門屏蔽后面的接口或者協(xié)議。
模板方法模式：
1、比如訂單的下單還有退款操作，都需要同時判斷使用的金額和紅包。
2、支付的時候，調(diào)用不同的支付方式，都需要去做判斷。
策略模式：
策略模式和裝飾器模式區(qū)別：
策略模式偏向于對實現(xiàn)方法或策略的封裝，調(diào)用者不需要考慮具體實現(xiàn)，只要指定使用的策略即可。
裝飾器模式一般用于需要對功能進行擴展的場合，每一種裝飾都是一種擴展或增強。
看起來兩個模式好像沒有必然的聯(lián)系，但是在實際使用過程中,發(fā)現(xiàn)了一個讓我困惑的地方。
先看一個典型的場景：
商場對客戶打折，老客戶8折，新客戶9折，新客戶購物滿3000，打8.5折
對這個基本場景，一般給的經(jīng)典模式是策略模式，很多書也以這個作為策略模式的的經(jīng)典案例。
但是，如果我把每一種折扣看作是一種對原有價格的裝飾，這個場景也是可以用裝飾器模式實現(xiàn)的。
兩個模式都需要花費一些代碼去判斷策略或裝飾器的類型，而且實現(xiàn)難度也旗鼓相當。
我用兩種模式都實現(xiàn)了相同的功能，但是卻沒有發(fā)現(xiàn)明顯的區(qū)別，不知道大家對這兩個模式怎么看，
歡迎討論。
策略模式更傾向是N選1的模式，也即根據(jù)條件選擇相應的算法，但各種算法是互斥的，比如：團體客戶和個人客戶的優(yōu)惠政策必然是非此即彼的；
裝飾模式是在主體邏輯的基礎(chǔ)上的附加邏輯，比如，個人客戶有的屬于同城客戶，支持送貨上門。
謝謝您的回復，如果按照策略模式，每一種打折方案是一種策略，而且只能選擇一個，這是沒有問題的。
按照裝飾模式，每一種折扣都是在購買金額上的附加，在沒有折上折或者送貨上門這些附加值的時候，我感覺裝飾模式也是實用的，當然，當折上折和送貨這種附加體現(xiàn)的時候，裝飾起的模式就體現(xiàn)去來了。
所以，我感覺在當前描述的問題中，這兩個模式應該都可以很恰當?shù)膶崿F(xiàn)需求，但是沒感覺到本質(zhì)的區(qū)別。
于是就有些困惑了，看了您的總結(jié)，我感覺自己有點鉆牛角了。
如果這個場景新增附加需求，比如新增vip客戶，那么策略模式就比較合適了。
但是如果進行折上折或者送貨上門這類附加需求，很明顯裝飾模式會更好一些了。
看來具體的模式還得根據(jù)實際需求確定，不能死搬硬套。
盡管樓主可以使用兩種模式實現(xiàn)自己說的場景，但是兩者還是有本質(zhì)的區(qū)別。
策略模式，已經(jīng)說的很清楚， 就不多說了。
裝飾模式是主題邏輯的基礎(chǔ)上的加強?？梢钥纯碕AVA IO的設(shè)計。
就像樓上說的， 如果客戶購買滿5000， 不只可以享受7折優(yōu)惠， 還可以送貨上門。
這里有兩項功能： 1） 7折優(yōu)惠， 2）送貨上門
如果使用策略模式， 我們勢必把兩項功能都寫在一個策略的實現(xiàn)類里面。
假使現(xiàn)在有新的場景出現(xiàn)，就是老客戶購買滿3000， 也享受送貨上門。（或者說這里面的還蘊藏一些其他的優(yōu)惠，比如說返券等等）
難道我們又把這些功能添加到我們的策略里面， 這樣代碼就很生硬而且不容易修改。
但是使用裝飾模式就不一樣，裝飾模式能動態(tài)的給對象增加特有的功能。 比如說IO里面可以添加Buffer的功能。 同樣在我們的場景里面，我們也可以將送貨上門、返券等也動態(tài)的增強， new 送貨上門（new 返券（））...., 這樣子就很靈活了。
策略實現(xiàn)可能類似：
do7折()；
do送貨上門（)；
do返券（）
裝飾的實現(xiàn)可能了類似：
new 7折（ new 送貨上門（new 返券（）））， 能隨意組合；
所有的優(yōu)惠都享受上了， 看上去還是爽一點。
其實裝飾模式， 還是更符合設(shè)計的一條原則： 少繼承， 多組合