超詳細：經常使用的設計模式彙總

時間  2020-11-29
標籤 數據庫 編程 windows 設計模式 安全 多線程 ide 學習 測試 優化 欄目 SQL 简体版
原文   原文鏈接

單例模式：

即一個應用程序中，某個類的實例對象只有一個，你沒有辦法去new，由於構造器是被private修飾的，通常經過其get方法獲取到他們的實例。數據庫

懶漢寫法（線程不安全）編程

public class Singleton {

private static Singleton singleton;

private Singleton() {
}

public static Singleton getInstance() {
 if (singleton == null) {
  singleton = new Singleton();
 }
 return singleton;
}
}

懶漢式寫法（線程安全）windows

public class Singleton {  
   private static Singleton instance;  
   private Singleton (){}  
   public static synchronized Singleton getInstance() {  
   if (instance == null) {  
       instance = new Singleton();  
   }  
   return instance;  
   }  
}

餓漢式寫法設計模式

public class Singleton {  
   private static Singleton instance = new Singleton();  
   private Singleton (){}  
   public static Singleton getInstance() {  
   return instance;  
   }  
}

靜態內部類安全

public class Singleton {  
   private static class SingletonHolder {  
   private static final Singleton INSTANCE = new Singleton();  
   }  
   private Singleton (){}  
   public static final Singleton getInstance() {  
   return SingletonHolder.INSTANCE;  
   }  
}

枚舉多線程

這種方式是Effective Java做者Josh Bloch 提倡的方式，它不只能避免多線程同步問題，並且還能防止反序列化從新建立新的對象，可謂是很堅強的壁壘啊，不過，我的認爲因爲1.5中才加入enum特性，用這種方式寫難免讓人感受生疏。ide

public enum Singleton {  
   INSTANCE;  
   public void whateverMethod() {  
   }  
}

雙重校驗鎖學習

public class Singleton {  
   private volatile static Singleton singleton;  
   private Singleton (){}  
   public static Singleton getSingleton() {  
   if (singleton == null) {  
       synchronized (Singleton.class) {  
       if (singleton == null) {  
           singleton = new Singleton();  
       }  
       }  
   }  
   return singleton;  
   }  
}

實際應用場景：測試

  1. 在Spring中建立的Bean實例默認都是單例模式存在的。優化

  2. Windows的Task Manager（任務管理器）就是很典型的單例模式（這個很熟悉吧），想一想看，是否是呢，你能打開兩個windows task manager嗎？不信你本身試試看哦~

  3. windows的Recycle Bin（回收站）也是典型的單例應用。在整個系統運行過程當中，回收站一直維護着僅有的一個實例。

  4. 網站的計數器，通常也是採用單例模式實現，不然難以同步。

  5. 應用程序的日誌應用，通常都何用單例模式實現，這通常是因爲共享的日誌文件一直處於打開狀態，由於只能有一個實例去操做，不然內容很差追加。

觀察者模式：

對象間一對多的依賴關係，當一個對象的狀態發生改變時，全部依賴於它的對象都獲得通知並被自動更新。

 

給你舉個栗子：假設有三我的，小美（女，22），小王和小李。小美很漂亮，小王和小李是兩個程序猿，時刻關注着小美的一舉一動。有一天，小美說了一句：「誰來陪我打遊戲啊。」

這句話被小王和小李聽到了，結果樂壞了，蹭蹭蹭，沒一下子，小王就衝到小美家門口了，在這裏，小美是被觀察者，小王和小李是觀察者，被觀察者發出一條信息，而後觀察者們進行相應的處理，看代碼：

public interface Person {
   //小王和小李經過這個接口能夠接收到小美髮過來的消息
   void getMessage(String s);
}

這個接口至關於小王和小李的電話號碼，小美髮送通知的時候就會撥打getMessage這個電話，撥打電話就是調用接口，看不懂不要緊，先往下看

public class LaoWang implements Person {

   private String name = "小王";

   public LaoWang() {
   }

   @Override
   public void getMessage(String s) {
       System.out.println(name + "接到了小美打過來的電話，電話內容是：" + s);
   }

}

public class LaoLi implements Person {

   private String name = "小李";

   public LaoLi() {
   }

   @Override
   public void getMessage(String s) {
       System.out.println(name + "接到了小美打過來的電話，電話內容是：->" + s);
   }

}

代碼很簡單，咱們再看看小美的代碼：

public class XiaoMei {
   List<Person> list = new ArrayList<Person>();
    public XiaoMei(){
    }

    public void addPerson(Person person){
        list.add(person);
    }

    //遍歷list，把本身的通知發送給全部暗戀本身的人
    public void notifyPerson() {
        for(Person person:list){
            person.getMessage("大家過來吧，誰先過來誰就能陪我一塊兒玩兒遊戲!");
        }
    }
}

咱們寫一個測試類來看一下結果對不對

public class Test {
   public static void main(String[] args) {

       XiaoMei xiao_mei = new XiaoMei();
       LaoWang lao_wang = new LaoWang();
       LaoLi lao_li = new LaoLi();

       //小王和小李在小美那裏都註冊了一下
       xiao_mei.addPerson(lao_wang);
       xiao_mei.addPerson(lao_li);

       //小美向小王和小李發送通知
       xiao_mei.notifyPerson();
   }
}

實際應用場景：

場景描述：

以購票爲核心業務(此模式不限於該業務)，但圍繞購票會產生不一樣的其餘邏輯，如：

  • 購票後記錄文本日誌

  • 購票後記錄數據庫日誌

  • 購票後發送短信

  • 購票送抵扣卷、兌換卷、積分
    -其餘各種活動等

傳統解決方案:

在購票邏輯等類內部增長相關代碼，完成各類邏輯。

存在問題：

一、一旦某個業務邏輯發生改變，如購票業務中增長其餘業務邏輯，須要修改購票核心文件、甚至購票流程。

二、日積月累後，文件冗長，致使後續維護困難。

存在問題緣由主要是程序的"緊密耦合"，使用觀察模式將目前的業務邏輯優化成"鬆耦合"，達到易維護、易修改的目的，同時也符合面向接口編程的思想。

觀察者模式典型實現方式：

  • 定義2個接口：觀察者（通知）接口、被觀察者（主題）接口

  • 定義2個類，觀察者對象實現觀察者接口、主題類實現被觀者接口

  • 主題類註冊本身須要通知的觀察者

  • 主題類某個業務邏輯發生時通知觀察者對象，每一個觀察者執行本身的業務邏輯。

裝飾者模式

對已有的業務邏輯進一步的封裝，使其增長額外的功能，如Java中的IO流就使用了裝飾者模式，用戶在使用的時候，能夠任意組裝，達到本身想要的效果。

舉個栗子，我想吃三明治，首先我須要一根大大的香腸，我喜歡吃奶油，在香腸上面加一點奶油，再放一點蔬菜，最後再用兩片面包夾一下，很豐盛的一頓午餐，養分又健康。那咱們應該怎麼來寫代碼呢？首先，咱們須要寫一個Food類，讓其餘全部食物都來繼承這個類，看代碼：

public class Food {

   private String food_name;

   public Food() {
   }

   public Food(String food_name) {
       this.food_name = food_name;
   }

   public String make() {
       return food_name;
   };
}

代碼很簡單，我就不解釋了，而後咱們寫幾個子類繼承它：

//麪包類
public class Bread extends Food {

   private Food basic_food;

   public Bread(Food basic_food) {
       this.basic_food = basic_food;
   }

   public String make() {
       return basic_food.make()+"+麪包";
   }
}

//奶油類
public class Cream extends Food {

   private Food basic_food;

   public Cream(Food basic_food) {
       this.basic_food = basic_food;
   }

   public String make() {
       return basic_food.make()+"+奶油";
   }
}

//蔬菜類
public class Vegetable extends Food {

   private Food basic_food;

   public Vegetable(Food basic_food) {
       this.basic_food = basic_food;
   }

   public String make() {
       return basic_food.make()+"+蔬菜";
   }

}

這幾個類都是差很少的，構造方法傳入一個Food類型的參數，而後在make方法中加入一些本身的邏輯，若是你仍是看不懂爲何這麼寫，不急，你看看個人Test類是怎麼寫的，一看你就明白了

public class Test {
   public static void main(String[] args) {
       Food food = new Bread(new Vegetable(new Cream(new Food("香腸"))));
       System.out.println(food.make());
   }
}

看到沒有，一層一層封裝，咱們從裏往外看：最裏面我new了一個香腸，在香腸的外面我包裹了一層奶油，在奶油的外面我又加了一層蔬菜，最外面我放的是麪包，是否是很形象，哈哈~ 這個設計模式簡直跟現實生活中一摸同樣，看懂了嗎？

實際應用場景：

如上述同樣，不一樣的人，選擇的搭配不一樣，對應價格也不相同，如果應用傳統方式你會發現這裏四種配料就要寫十幾種實現類了，那若是咱們的配料是二十幾種或者三十幾種呢，那麼使用繼承這種 方式確定會使咱們的子類爆炸。

經過不一樣的組合以Food food = new Bread(new Vegetable(new Cream(new Food("香腸"))));形式更加簡化，結構更加清楚的方式展示。

優勢：

  • 把類中的裝飾功能從類中搬除，能夠簡化原來的類

  • 能夠把類的 核心職責和裝飾功能區分開來，結構清晰 明瞭而且能夠去除相關類的重複的裝飾邏輯。

適配器模式

將兩種徹底不一樣的事物聯繫到一塊兒，就像現實生活中的變壓器。假設一個手機充電器須要的電壓是20V，可是正常的電壓是220V，這時候就須要一個變壓器，將220V的電壓轉換成20V的電壓，這樣，變壓器就將20V的電壓和手機聯繫起來了。

public class Test {
   public static void main(String[] args) {
       Phone phone = new Phone();
       VoltageAdapter adapter = new VoltageAdapter();
       phone.setAdapter(adapter);
       phone.charge();
   }
}

// 手機類
class Phone {

   public static final int V = 220;// 正常電壓220v，是一個常量

   private VoltageAdapter adapter;

   // 充電
   public void charge() {
       adapter.changeVoltage();
   }

   public void setAdapter(VoltageAdapter adapter) {
       this.adapter = adapter;
   }
}

// 變壓器
class VoltageAdapter {
   // 改變電壓的功能
   public void changeVoltage() {
       System.out.println("正在充電...");
       System.out.println("原始電壓：" + Phone.V + "V");
       System.out.println("通過變壓器轉換以後的電壓:" + (Phone.V - 200) + "V");
   }
}

 

適配器模式應用場景

類適配器與對象適配器的使用場景一致，僅僅是實現手段稍有區別，兩者主要用於以下場景：

  • 想要使用一個已經存在的類，可是它卻不符合現有的接口規範，致使沒法直接去訪問，這時建立一個適配器就能間接去訪問這個類中的方法。

  • 咱們有一個類，想將其設計爲可重用的類（可被多處訪問），咱們能夠建立適配器來將這個類來適配其餘沒有提供合適接口的類。

以上兩個場景其實就是從兩個角度來描述一類問題，那就是要訪問的方法不在合適的接口裏，一個從接口出發（被訪問），一個從訪問出發（主動訪問）。

接口適配器使用場景：

  • 想要使用接口中的某個或某些方法，可是接口中有太多方法，咱們要使用時必須實現接口並實現其中的全部方法，可使用抽象類來實現接口，並不對方法進行實現（僅置空），而後咱們再繼承這個抽象類來經過重寫想用的方法的方式來實現。這個抽象類就是適配器。

工廠模式

簡單工廠模式：一個抽象的接口，多個抽象接口的實現類，一個工廠類，用來實例化抽象的接口

// 抽象產品類
abstract class Car {
   public void run();

   public void stop();
}

// 具體實現類
class Benz implements Car {
   public void run() {
       System.out.println("Benz開始啓動了。。。。。");
   }

   public void stop() {
       System.out.println("Benz停車了。。。。。");
   }
}

class Ford implements Car {
   public void run() {
       System.out.println("Ford開始啓動了。。。");
   }

   public void stop() {
       System.out.println("Ford停車了。。。。");
   }
}

// 工廠類
class Factory {
   public static Car getCarInstance(String type) {
       Car c = null;
       if ("Benz".equals(type)) {
           c = new Benz();
       }
       if ("Ford".equals(type)) {
           c = new Ford();
       }
       return c;
   }
}

public class Test {

   public static void main(String[] args) {
       Car c = Factory.getCarInstance("Benz");
       if (c != null) {
           c.run();
           c.stop();
       } else {
           System.out.println("造不了這種汽車。。。");
       }

   }

}

工廠方法模式：有四個角色，抽象工廠模式，具體工廠模式，抽象產品模式，具體產品模式。再也不是由一個工廠類去實例化具體的產品，而是由抽象工廠的子類去實例化產品

// 抽象產品角色
public interface Moveable {
   void run();
}

// 具體產品角色
public class Plane implements Moveable {
   @Override
   public void run() {
       System.out.println("plane....");
   }
}

public class Broom implements Moveable {
   @Override
   public void run() {
       System.out.println("broom.....");
   }
}

// 抽象工廠
public abstract class VehicleFactory {
   abstract Moveable create();
}

// 具體工廠
public class PlaneFactory extends VehicleFactory {
   public Moveable create() {
       return new Plane();
   }
}

public class BroomFactory extends VehicleFactory {
   public Moveable create() {
       return new Broom();
   }
}

// 測試類
public class Test {
   public static void main(String[] args) {
       VehicleFactory factory = new BroomFactory();
       Moveable m = factory.create();
       m.run();
   }
}

抽象工廠模式：與工廠方法模式不一樣的是，工廠方法模式中的工廠只生產單一的產品，而抽象工廠模式中的工廠生產多個產品

//抽象工廠類
public abstract class AbstractFactory {
   public abstract Vehicle createVehicle();
   public abstract Weapon createWeapon();
   public abstract Food createFood();
}
//具體工廠類，其中Food,Vehicle，Weapon是抽象類，
public class DefaultFactory extends AbstractFactory{
   @Override
   public Food createFood() {
       return new Apple();
   }
   @Override
   public Vehicle createVehicle() {
       return new Car();
   }
   @Override
   public Weapon createWeapon() {
       return new AK47();
   }
}
//測試類
public class Test {
   public static void main(String[] args) {
       AbstractFactory f = new DefaultFactory();
       Vehicle v = f.createVehicle();
       v.run();
       Weapon w = f.createWeapon();
       w.shoot();
       Food a = f.createFood();
       a.printName();
   }
}

工廠模式例子不少，我大概說一下上面三種的特色：

  1. 簡單工廠模式：每次擴展時，須要添加一個類，並修改工廠類代碼，給get方法添加一條分支。

  2. 工廠方法模式：它與簡單工廠的區別就在於有多個工廠，每一個工廠只專一生產一種產品，當須要修改獲取的產品時，只須要修改所訪問的工廠就行。

  3. 抽象工廠模式：每次擴展時，須要添加1個類，並添加1個對應工廠。既是優勢（擴展靈活，不須要修改舊的類）又是缺點（老是要編寫新工廠）。

代理模式（proxy）

有兩種，靜態代理和動態代理。先說靜態代理，不少理論性的東西我不講，我就算講了，大家也看不懂。什麼真實角色，抽象角色，代理角色，委託角色。。。亂七八糟的，我是看不懂。

以前學代理模式的時候，去網上翻一下，資料一大堆，打開連接一看，基本上都是給你分析有什麼什麼角色，理論一大堆，看起來很費勁，不信的話大家能夠去看看，我是看不懂他們在說什麼。咱不來虛的，直接用生活中的例子說話。

注意：我這裏並非否認理論知識，我只是以爲有時候理論知識晦澀難懂，喜歡挑刺的人一邊去，你是來學習知識的，不是來挑刺的

到了必定的年齡，咱們就要結婚，結婚是一件很麻煩的事情，（包括那些被父母催婚的）。有錢的家庭可能會找司儀來主持婚禮，顯得熱鬧，洋氣～好了，如今婚慶公司的生意來了，咱們只須要給錢，婚慶公司就會幫咱們安排一整套結婚的流程。

整個流程大概是這樣的：家裏人催婚->男女雙方家庭商定結婚的黃道即日->找一家靠譜的婚慶公司->在約定的時間舉行結婚儀式->結婚完畢

婚慶公司打算怎麼安排婚禮的節目，在婚禮完畢之後婚慶公司會作什麼，咱們一律不知。。。別擔憂，不是黑中介，咱們只要把錢給人家，人家會把事情給咱們作好。因此，這裏的婚慶公司至關於代理角色，如今明白什麼是代理角色了吧。

代碼實現請看：

//代理接口
public interface ProxyInterface {
//須要代理的是結婚這件事，若是還有其餘事情須要代理，好比吃飯睡覺上廁所，也能夠寫
void marry();
//代理吃飯(本身的飯，讓別人吃去吧)
//void eat();
//代理拉屎，本身的屎，讓別人拉去吧
//void shit();
}

文明社會，代理吃飯，代理拉屎什麼的我就不寫了，有傷社會風化～～～能明白就好

好了，咱們看看婚慶公司的代碼:

public class WeddingCompany implements ProxyInterface {

private ProxyInterface proxyInterface;

public WeddingCompany(ProxyInterface proxyInterface) {
 this.proxyInterface = proxyInterface;
}

@Override
public void marry() {
 System.out.println("咱們是婚慶公司的");
 System.out.println("咱們在作結婚前的準備工做");
 System.out.println("節目彩排...");
 System.out.println("禮物購買...");
 System.out.println("工做人員分工...");
 System.out.println("能夠開始結婚了");
 proxyInterface.marry();
 System.out.println("結婚完畢，咱們須要作後續處理，大家能夠回家了，其他的事情咱們公司來作");
}

}

看到沒有，婚慶公司須要作的事情不少，咱們再看看結婚家庭的代碼:

public class NormalHome implements ProxyInterface{

@Override
public void marry() {
 System.out.println("咱們結婚啦～");
}

}

這個已經很明顯了，結婚家庭只須要結婚，而婚慶公司要包攬一切，前先後後的事情都是婚慶公司來作，據說如今婚慶公司很賺錢的，這就是緣由，乾的活多，能不賺錢嗎？

來看看測試類代碼：

public class Test {
public static void main(String[] args) {
 ProxyInterface proxyInterface = new WeddingCompany(new NormalHome());
 proxyInterface.marry();
}
}

運行結果以下：

這裏能夠看出代理模式與裝飾模式很類似，這裏簡單介紹下其區別：

代理模式（Proxy 模式）可理解爲：我想作，但不能作，我須要有一個能幹的人來幫我作。即：代理，偏重因本身沒法完成或本身無需關心，須要他人干涉事件流程，更多的是對對象的控制。

裝飾器模式（Decorator 模式）可理解爲：我想作，但不能作，我須要有各種特長的人來幫我作，但我有時只須要一我的，有時又須要不少人。即：裝飾，偏重對原對象功能的擴展，擴展後的對象還是是對象自己。

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程