Ⅰ JAVA中的適配器模式和策略模式的區別在哪
直接從字面上看也復是兩個完制全不同的模式；
從歸類上也是一個是結構模式，一個是行為模式；
從定義角度：一個是將一個類的介面轉換成客戶希望的另外一個介面，從而使原本因介面不兼容不能一起工作的類可以一起工作；
一個是把一系列演算法封裝起來，提供一個統一的介面給客戶，並使這些演算法可以相互間替換；
Ⅱ 關於策略模式的疑惑。
擴展開發，對修改關閉
對於Sorter來說,類本身並沒有改變.
既使你再多寫幾個類回繼承那個抽象類答.
Sorter還是不會改變.
不知道對不對,也是看了你的代碼才查的.
PS:老總是不可以換的,工作還是要做的..
軍師可以換.不要小看軍師.換了以後,工作做成什麼樣兒可沒准兒.
什麼覺得做得不好.
來,我讓你當兩天軍師!
你就是做到天上去,我還是老總,.嘿嘿!
Ⅲ 橋接模式和策略模式的區別
橋接(Bridge)模式是結構型模式的一種，而策略(strategy)模式則屬於行為模式。以下是它們的UML結構圖。
在橋接模式中，Abstraction通過聚合的方式引用Implementor。
從他們的結構圖可知，在這兩種模式中，都存在一個對象使用聚合的方式引用另一個對象的抽象介面的情況，而且該抽象介面的實現可以有多種並且可以替換。可以說兩者在表象上都是調用者與被調用者之間的解耦，以及抽象介面與實現的分離。
那麼兩者的區別體現在什麼地方呢？
1. 首先，在形式上，兩者還是有一定區別的，對比兩幅結構圖，我們可以發現，在橋接模式中不僅Implementor具有變化（ConcreateImplementior），而且Abstraction也可以發生變化（RefinedAbstraction），而且兩者的變化是完全獨立的，RefinedAbstraction與ConcreateImplementior之間鬆散耦合，它們僅僅通過Abstraction與Implementor之間的關系聯系起來。而在策略模式中，並不考慮Context的變化，只有演算法的可替代性。
2. 其次在語意上，橋接模式強調Implementor介面僅提供基本操作，而Abstraction則基於這些基本操作定義更高層次的操作。而策略模式強調Strategy抽象介面的提供的是一種演算法，一般是無狀態、無數據的，而Context則簡單調用這些演算法完成其操作。
3.橋接模式中不僅定義Implementor的介面而且定義Abstraction的介面，Abstraction的介面不僅僅是為了與Implementor通信而存在的，這也反映了結構型模式的特點：通過繼承、聚合的方式組合類和對象以形成更大的結構。在策略模式中，Startegy和Context的介面都是兩者之間的協作介面，並不涉及到其它的功能介面，所以它是行為模式的一種。行為模式的主要特點就是處理的是對象之間的通信方式，往往是通過引入中介者對象將通信雙方解耦，在這里實際上就是將Context與實際的演算法提供者解耦。
所以相對策略模式，橋接模式要表達的內容要更多，結構也更加復雜。橋接模式表達的主要意義其實是介面隔離的原則，即把本質上並不內聚的兩種體系區別開來，使得它們可以鬆散的組合，而策略在解耦上還僅僅是某一個演算法的層次，沒有到體系這一層次。從結構圖中可以看到，策略的結構是包容在橋接結構中的，橋接中必然存在著策略模式，Abstraction與Implementor之間就可以認為是策略模式，但是橋接模式一般Implementor將提供一系列的成體系的操作，而且Implementor是具有狀態和數據的靜態結構。而且橋接模式Abstraction也可以獨立變化。
Ⅳ 策略模式實際上應用了什麼設計原則
1.Petshop中策略模式的應用
至於在程序中的應用，我也是個新手，不知道何時需要這種模式，可以參考下petshop中的策略模式，理解下在真實項目中如何使用。我對petshop中策略模式的理解就是裡面處理訂單時可能有同步和非同步插入數據兩種方式，具體用那種方式直接在配置文件中修改即可。
看文字不如看圖片，自己畫了畫UML圖，不會用工具但是意思差不多。
這是IBLLStrategy類庫中的介面IBLLStrage，為了同步非同步插入訂單的實現，如果有新的訂單插入方式，可以繼承此介面這兩個類是處理同步非同步的訂單類。
繼承於IBLLStrage，分別實現自己的插入方法。在BLL層中的order類中
private static readonly PetShop.IBLLStrategy.IOrderStrategy orderInse
rtStrategy = LoadInsertStrategy();LoadInsertStrategy
方法決定了實例化
的是同步傳送訂單還是非同步傳送訂單。在BLL邏輯層中，Order訂單中會改變的是insert方法，所以根據設計原則，把需要改變的獨立出來。
2.控制台小應用程序
實例描述，模擬鴨子應用，由於後期需要可能有N種鴨子，鴨子可不可以飛，怎樣飛，鴨子可不可以叫，怎麼叫，如果僅僅寫兩個介面Ifly和Iquack，子類要麼繼承，要麼不繼承，對飛的行為無法控制，因為飛的動作和叫的方式千變萬化。
設計原則
1.找出應用中可能需要變化之處，把他們獨立出來，不要和那些不需要變化的代碼混合在一起（此例子中鴨子的行為屬於變化）
2.針對介面編程，而不是針對實現編程針對介面編程是真正的意思是針對超類型編程，利用多態，程序可以針對超類型編程，聲明一個類時通常是一個超類或者是一個介面，這也意味著聲明類時，不用理會以後執行的真正對象，舉例Animal是一個抽象類，有兩個子類Dog和Cat
繼承Animal針對實現的編程是:
Cat c = new Cat();
c.meow();
//
貓叫的方式
Dog d = new Dog();
d.bark();
//
狗叫的方式針對介面的編程是：
Animal a = new Dog();
a.makeSound();
//makeSound中會調用bark();
Animal a = new Cat();
a.makeSound();
//makeSound中會調用meow();
3.多用組合，少用繼承根據讀headfirst策略模式做的c#的例子。
策略模式：定義了演算法族，分別封裝起來，讓他們之間可以相互替換，次模式讓演算法的變化獨立於使用演算法的客戶。
Ⅳ 策略模式的概念
（原文：The Strategy Pattern defines a family of algorithms,encapsulates each one,and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.）
Context(應用場景):
1、需要使用ConcreteStrategy提供的演算法。
2、 內部維護內一個Strategy的實例。
3、 負責動態容設置運行時Strategy具體的實現演算法。
4、負責跟Strategy之間的交互和數據傳遞。
Strategy(抽象策略類)：
1、 定義了一個公共介面，各種不同的演算法以不同的方式實現這個介面，Context使用這個介面調用不同的演算法，一般使用介面或抽象類實現。
ConcreteStrategy(具體策略類)：
2、 實現了Strategy定義的介面，提供具體的演算法實現。
Ⅵ 如何利用工廠模式與策略模式實現商場收銀系統
工廠模式是抄創建型模式襲 策略模式是行為性模式 一個關注對象創建 一個關注行為的封裝 策略模式就是定義一系列的演算法，這些演算法可以在需要的時候替換和擴展．工廠模式是生成型的模式，在你需要的時候構建具體的實例． 在下面的情況下應當考慮使用策...
Ⅶ 微信營銷的策略模式 五種策略模式有哪些
當你把客戶吸引到了微信上，你只是成功了第一步。
因為他們只是對你的服務產生了一丟丟興趣，但是還沒有完全的信任你，也沒有決定要購買你。
你要如何利用那一丟丟的興趣，讓客戶從信任到購買呢？
如何建立信任：
1、具有說服力的案例
我見過很多做微信營銷的人，對於自己的客戶案例諱莫如深，根本就不告訴你到底是有什麼成功案例。我該如何相信你？你也只不過是個陌生人而已，我可不敢立刻給你轉賬。所以，就算是編，也要把客戶案例整理出來好嗎？
2、具有說服力的背書平台
如果你的服務是在另外一個正規平台上售賣，那麼你的可信度就大大提高了。因為平台是具備信用背書的。比如你是賣資料的，你在騰訊課堂開過課，那麼大家會把你當做專家看待，自然就會放心的購買服務。
3、具有說服力的自媒體
當你有一個粉絲上萬的自媒體號的時候，你本人就已經有了信用背書。想想啊，你必須經常更文，經常跟粉絲互動，才能攢到這么多粉絲，做了這么久都沒有跑，應該是相對穩定的。
如何讓顧客互相轉介紹：
c端顧客，重點是看占沒佔到便宜，能佔到便宜的事情，他們是跳著高做的。
所以讓他們占以下幾個便宜：
1）試用便宜
把你的用戶都加到一個群里，借口就是進入可以申請試用，他們加進來告知，拉好友再贈他和好友各一個贈品；他為了佔便宜，就要拉人。
2）拼單便宜
當你的群建立起來之後，在群里搞拼團活動，閨蜜團、同學團、同事團，只要拉人來，就能讓所有人享受一樣的優惠。
3）拉客分佣
對待那些鐵粉，比如消費前幾名的顧客，發展成代理。因為他們就是忠實使用者，一定深知產品的優勢，讓他們去幫你推薦，然後根據訂單返佣。
Ⅷ 策略模式 里的一個小問題
為了調用你的其他策略類呀 根據傳入不同的參數 然後你new 出不同的策略。
希望能幫到你！
Ⅸ 策略模式和生成器模式怎麼覺得根本就是一個套路，類圖一樣，連演算法都一樣，策略模式的context不就
我上午不來是答過你自么：區別還是比較明顯的吧，Builder的目的是希望用同樣的生產過程，根據不同的生產者得到不同的產品。而外觀模式則是將多個對象組合起來，它不需要生產者，也不需要得到不同的結果。有點象虛函數和普通函數的區別。
Ⅹ 策略模式的出行旅遊：
<?php/***策略模式*定義一系列的演算法,把每一個演算法封裝起來,並且使它們可相互替換。*本模式使得演算法可獨立於使用它的客戶變化*//***出行旅遊*/interfaceTravelStrategy{publicfunctiontravelAlgorithm();}/***具體策略類(ConcreteStrategy)*1：乘坐飛機*/{publicfunctiontravelAlgorithm(){echotravelbyAirPlain,<BR> ;}}/***具體策略類(ConcreteStrategy)*2：乘坐火車*/{publicfunctiontravelAlgorithm(){echotravelbyTrain,<BR> ;}}/***具體策略類(ConcreteStrategy)*3：騎自行車*/{publicfunctiontravelAlgorithm(){echotravelbyBicycle,<BR> ;}}/****環境類(Context):*用一個ConcreteStrategy對象來配置。*維護一個對Strategy對象的引用。可定義一個介面來讓Strategy訪問它的數據。*演算法解決類，以提供客戶選擇使用何種解決方案：*/classPersonContext{private$_strategy=null;publicfunction__construct(TravelStrategy$travel){$this->_strategy=$travel;}/***旅行*/(TravelStrategy$travel){$this->_strategy=$travel;}/***旅行*/publicfunctiontravel(){return$this->_strategy->travelAlgorithm();}}//乘坐火車旅行$person=newPersonContext(newTrainStrategy());$person->travel();//改騎自行車$person->setTravelStrategy(newBicycleStrategy());$person->travel();?>