設計模式讀書筆記（二）設計模式之創建模式

来源:http://www.cnblogs.com/heKaiXi/archive/2017/07/04/dp-create.html
-Advertisement-
Play Games

設計模式的分類創建模式單例模式工廠方法模式抽象工廠模式建造者模式原型模式設計模式的分類java設計模式中共23種模式，根據功能和特點可歸為3類今天進行分享的就是創建模式中相關的設計模式創建模式單例模式單例模式: 一個相對簡單的模式，目的是確保某一個類只有一個實例，而且自行實例化並向整個系統提供實例... ...


設計模式的分類

java設計模式中共23種模式，根據功能和特點可歸為3類



今天進行分享的就是創建模式中相關的設計模式

創建模式

單例模式

單例模式: 一個相對簡單的模式，目的是確保某一個類只有一個實例，而且自行實例化並向整個系統提供實例。

根據以上定義中的要點，相信很多童鞋已經可以自己寫出單例模式的簡單實現了，下麵進行簡單說明



//餓漢式
public class SingletonHungry {
    private String name;
    /**
     * 構造函數私有化 不允許其他類實例化
     */
    private SingletonHungry(String name) {
        this.name = name;
    }
    
    /**
     * 私有靜態常量實例化 類初始化時創建實例 自行實例化
     */
    private static final SingletonHungry single = new SingletonHungry("hekx");  
    
    /**
     * 公有靜態訪問方法提供實例獲取
     * @return
     */
    public static SingletonHungry getInstance() {  
        return single;  
    }

    public String getName() {
        return name;
    }

}



public class SingletonLazy {
    //懶漢式
    /**
     * 持有私有靜態實例，防止被引用，此處賦值為null，目的是實現延遲載入
     */
    private SingletonLazy(){}
    
    /**
     * 私有靜態全局變數初始化為空
     */
    private static SingletonLazy single= null;
    public static SingletonLazy getInstance(){
        if(single == null){
            single = new SingletonLazy();
        }
        return single;
    }
}

以上是最簡單的單例模式的實現方式，在此我們簡單總結一下單例模式的優點

  • 在記憶體中只存在一個實例，減少記憶體開支，特別對於一個對象需要頻繁創建、銷毀，而且創建或銷毀時無法保證性能時，單例模式的優勢就很明顯了
  • 若對象的產生需要消耗較多的資源，則也應該以單例模式在應用啟動時創建生成對象，永久駐留在記憶體中

缺點：

  • 一般沒有介面，存在不利於擴展的問題
  • 並行測試中如果單例對象未能及時創建完成，可能導致嚴重出錯
  • 單例模式與單一職責原則有衝突，因為它將"單例"與"業務"融合在一個類中

上面的慄子中，都是最簡單的實現，懶漢式也存在多線程環境下的隱患，雖然可以加synchronized關鍵字進行鎖判定，但始終會存在jvm級別的隱患，所以還是推薦使用餓漢式的單例模式，在程式啟動時自動創建一次
其次，需要考慮對象複製的情況。java中，對象預設不能被覆制，但如果實現了cloneable介面並實現了clone方法，則可以直接通過對象複製方式創建一個新對象，對象複製是不用調用類的構造函數，因此即便是私有構造函數，對象仍然可被覆制。解決方案最好是單例類不要實現cloneable介面

而根據餓漢式的原則，在程式啟動時創建實例，所以也有各種方式去實現，比如內部類等等，其原理都是一樣的，在這就不一一列舉了，從本質上講設計模式本身是針對某一類問題的解決思想，而非固定的代碼片段，所以學習和掌握的重點應該是各種模式的核心思想和對應解決的問題

那現在來個急轉彎，單例的思想和實現已經瞭然，如果某實例最多可以有3個或者其他指定數量，又該如何實現呢



public class ManyObject {
    //設置實例的最大數量
    private static int maxNum = 2;
    //實例集合
    private static ArrayList<ManyObject> objs = new ArrayList<ManyObject>();
    //訪問下標
    private static int index = 0;
    //將原來實例化的部分改為實例化指定數量
    static{
        for(int i=0; i<maxNum; i++){
            objs.add(new ManyObject());
        }
    }
    private ManyObject(){}
    //隨機獲取
    public static ManyObject getInstance(){
        Random random = new Random();
        index = random.nextInt(maxNum);
        return objs.get(index);
    }
}

單例模式相對簡單，在spring中創建bean的方案，預設就是單例模式，所以各位做web的朋友應該是經常接觸的，這樣的優點就是Spring容器可以管理這些bean的生命周期，決定什麼時候創建出來，什麼時候銷毀，銷毀時的處理等等，如果採用非單例模式，(eg:prototype)則bean初始化後的管理交給J2EE容器，Spring容器不在跟蹤管理Bean生命周期

工廠方法模式

工廠方法模式：創建一個工廠類，並對實現同一介面的類進行實例創建

下麵讓我們舉個慄子:
場景：從工廠類中創建不同種類的人



首先我們需要一個人類的介面,以及不同的人種的實現類

public interface Human {
    void getColor();
    void talk();
}

public class BlackHuman implements Human{
    @Override
    public void getColor() {
        System.out.println("黑色肌膚");
    }
    @Override
    public void talk() {
        System.out.println("部落語言");
    }
}

public class WhiteHuman implements Human{
    @Override
    public void getColor() {
        System.out.println("白色肌膚");
    }
    @Override
    public void talk() {
        System.out.println("俄羅斯語");
    }
}

public class YellowHuman implements Human{
    @Override
    public void getColor() {
        System.out.println("黃色肌膚");
    }
    @Override
    public void talk() {
        System.out.println("流利的川普");
    }
}

然後我們需要一個工廠

public abstract class AbstractHumanFactory {
    public abstract Human creatHuman(String type);
}

public class Factory extends AbstractHumanFactory{
    @Override
    public Human  creatHuman(String type) {
        switch (type) {
        case "white":
            return new WhiteHuman();
        case "yellow":
            return new YellowHuman();
        default:
            return new BlackHuman();
        }
    }
}

現在我們可以開始通過工廠創建人的實例了

public class Main {
    private static Human human = null;
    public static void main(String[] args) {
        AbstractHumanFactory factory = new Factory();
        human  = factory.creatHuman("black");
        human.talk();
        human.getColor();
    }
}

以上就是工廠方法模式的基本使用，下麵給出工廠方法模式的定義

定義一個用於創建對象的介面，讓子類決定實例化哪一個類。工廠方法使一個類的實例化延遲到其子類。

工廠方法模式的通用類圖


工廠方法模式的優點:

  1. 良好的封裝，代碼結構清晰。調用者只需傳遞簡單的參數即可生成對象，屏蔽了創建對象的細節，降低了模塊之間的耦合
  2. 良好的擴展性。增加產品類的情況下，適當地修改具體工廠類或擴展一個即可
  3. 屏蔽了產品類，調用者無需關心產品類的實現及變化，只需要關心產品的介面，只要介面不變，上層模塊就不要發生變化。
  4. 典型的解耦框架。高層模塊只需要知道產品的抽象類，其他的實現類都不用關心，符合迪米特法則(我不需要的就不交流)、依賴倒置原則(只依賴產品類的抽象)、里氏替換原則(子類可替換產品父類)

運用場景：

  1. 工廠方法模式是new一個對象的替代品，所以在所有需要生成對象的地方都可以使用，但也需要考慮是否要增加一個工廠類進行管理，增加代碼複雜度
  2. 需要靈活的、可擴展的框架時，可以考慮工廠方法模式。
  3. 可以使用在異構項目中(例如webservice與一個非java項目交互)

工廠方法模式的擴展：

  1. 縮小為簡單工廠模式

    如果一個模塊只需要一個工廠，所以沒有必要去實例化一個工廠類，可以直接使用靜態方法去創建我們想要的對象，對之前創建人類的設計做如下改進

    

  2. 升級為多個工廠類

    如果初始化一個對象很費精力的情況下，所有的產品類都放到一個工廠中進行初始化會使得代碼結構不清晰。依舊舉個慄子，一個產品有5個具體實現，每個實現類的初始化(不僅僅是new,初始化包括new對象,並對對象設置一定的初始值)方法均不相同,如果寫在一個工廠方法中，勢必顯得不夠完美。現在我們仍以創建不同人類為慄子，每種人都擁有自己的工廠，更改為如下設計
    

  3. 替代單例模式

    單例模式的核心要求就是記憶體中只有一個對象，通過工廠方法模式也可以實現記憶體中只產生一個對象
    

        public class Singleton {
        private Singleton(){}
        public void doSomeThing(){
            System.out.println("業務處理中");
        } 
    }

    public class SingletonFactory {
        private static Singleton singleton = null;
        static{
          try {
            Class<?> cl = Class.forName(Singleton.class.getName());
            //獲取無參構造
            Constructor<?> constructor = cl.getDeclaredConstructor();
            //設置無參構造可訪問
            constructor.setAccessible(true);
            //實例化對象
            singleton = (Singleton) constructor.newInstance();
        } catch (Exception e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }
    }
    public static Singleton getSingleton(){
        return singleton;
    }
}

  4. 延遲初始化

    一個對象被消費完畢後，並不立刻釋放，工廠類保持其初始化狀態，等待再次被使用。
    在下麵的慄子中，如果Map中已經有對像，則直接取出返回，如果沒有，則產生一個放入Map，方便下次調用。
    延遲載入還能用在對象初始化比較複雜的情況下，例如硬體訪問，涉及多方面的交互，則可以通過延遲載入降低對象產生和銷毀帶來的複雜性。
    

    public class ProductFactory {
    private static final Map<String,Product> prMap = new HashMap<String,Product>();
    public static synchronized Product createProduct(String type) throws Exception{
        Product product = null;
        if(prMap.containsKey(type)){
            product = prMap.get(type);
        }else{
            if(type.equals("methon1")){
                product = new ConcreteProduct();
            }
            prMap.put(type, product);
        }
        return product;
    }
}

抽象工廠模式

對上面創建人類的設計進行修改，以便於更靈活的創建不同性別或者其他屬性的人類。



抽象工廠模式：為創建一組相關或相互依賴的對象提供一個介面，而無需指定他們的具體類。

抽象工廠模式是工廠方法模式的升級，在有多個業務品種、業務分類時，通過抽象工程模式需要的對象是一種非常好的解決方式。

下麵給出抽象工廠通用類圖：


下麵舉一個慄子：
兩個產品，分別有兩種實現方式，構建抽象工廠進行對象創建。


    AbstractCreator c1 = new Creator1();
    AbstractCreator c2 = new Creator2();
        
    AbstractProductA a1 = c1.createProductA();
    AbstractProductA a2 = c2.createProductA();
        
    AbstractProductB b1 = c1.createProductB();
    AbstractProductB b2 = c2.createProductB();

設計中，沒有任何一個方法與實現類有關係，對於一個產品來說，我們只要知道他的工廠方法就可以直接產生一個產品對象，無需關心其實現類。


抽象工廠模式優點：

  1. 封裝性，每個產品實現類不是高層需要關心的，關心的是介面、抽象，它不關心對象是如何創建出來的，因為這些都由工廠類負責，只需要知道工廠類，就能創建出需要的對象。
  2. 產品族內的約束為非公開狀態，具體的產品族內的約束是在工廠內實現的。

抽象工廠模式缺點：

  1. 產品族擴展非常困難。例如上面的慄子中，如果擴展產品族，則需要增加產品C，AbstractCreator裡面增加createProductC()，然後修改兩個實現類。嚴重違反了開閉原則。所有與契約(抽象類和介面)有關係的代碼都要修改，有侵害的危險。


抽象工廠模式使用場景：
一個對象族(或者一組沒有任何關係的對象)都有相同的約束，則可以使用抽象工廠模式。
[對於不同操作系統下的文本編輯器和圖片編輯器，擁有相同的行為，但具體實現是不同的，而相同的約束就是操作系統]


抽象工廠模式註意事項：
抽象工廠模式擴展產品族比較困難，但產品等級非常容易擴展【橫向擴展容易，縱向擴展困難】

建造者模式

工廠類模式提供的是創建單個類的模式，而建造者模式則是將各個產品集中起來進行管理，用來創建複合對象(某個類具有不同屬性)

下麵我們來模擬一個場景：對於車模型提供不同的實現，併在客戶端由客戶指定順序調用實現類的行為。對此我們做如下設計。


客戶端中，我們通過sequence指定實現類的行為調用順序，在實現類run()中進行一次調用。但客戶的需求是不斷變動的，如果每個實現的調用順序不相同，這種實現就顯得不足以應對了。所以對每種模型產品定義一個建造者，將需要的順序告訴建造者由他創建。更改設計如下：



        CarBuilder benzBuild = new BenzBuilder();
        benzBuild.setSequence(sequence);
        CarModel car = benzBuild.getCarModel();
        car.run();

若在不能預知客戶需要的什麼順序的模型的情況下，再一次進行封裝，指揮各個事件的先後順序，為每種順序指定一個代碼。修改設計為如下：



增加了導演類，將各種可能出現的模型(車型及調用順序的組合)通過方法實現

public class Director {
    private ArrayList<String> sequence =  new ArrayList<String>();
    private BenzBuilder benzb =  new BenzBuilder();
    private BMWBuilder bmwb =  new BMWBuilder();
    
    public BenzModel getABenzModel(){
        this.sequence.clear();
        this.sequence.add("start");
        this.sequence.add("stop");
        this.benzb.setSequence(this.sequence);
        return (BenzModel) this.benzb.getCarModel();
    }
    
    public BMWModel getCBMWModel(){
        this.sequence.clear();
        this.sequence.add("engine");
        this.sequence.add("start");
        this.sequence.add("stop");
        this.benzb.setSequence(this.sequence);
        return (BMWModel) this.bmwb.getCarModel();
    }
    ...
}

以上就是建造者模式的簡單實現了。

建造者模式:也叫生成器模式，將一個複雜對象的構建與表示分離，使得同樣的構建過程可以創建不同的表示。

建造者模式通用類圖：


  • 產品類：通常實現模板方法模式，擁有模板方法和基本方法。
  • Builder抽象建造者：規範產品的組建，一般是由子類實現。
  • ConcreteBuilder具體建造者：實現抽象類定義的所有方法，並且返回一個組建好的對象。
  • 導演類：負責安排已有模塊的順序，告訴Builder開始建造

建造者模式優點：

  • 封裝性：客戶端不必知道產品內部組成的細節，不需要關心模型內部是如何實現的
  • 擴展性：各種模型之間相互獨立，對系統擴展非常有利
  • 控制細節風險：由於建造者之間獨立，因此可以對建造過程逐步細化，不對其他模塊產生任何影響

使用場景：

  • 相同的方法，不同的執行順序，產生不同的事件結果
  • 多個部件或零件，都可以裝配到一個對象中，但是產生的運行結果又不相同
  • 產品類非常複雜，或者產品類中的調用順序不同產生了不同的效能
  • 對象創建過程中會使用到系統中的一些其他對象，這些對象在產品對象的創建過程中不易得到時，可以採用建造者模式封裝該對象的創建過程。

註意事項：
建造者模式關註的是零件類型的裝配工藝(順序)，而工廠方法則重點是創建。這是與工廠方法模式最大不同的地方，雖然同為創建類模式，但關註點不同。

原型模式

原型模式：用原型實例指定創建對象的種類，並通過拷貝這些原型創建新的對象。【不通過new關鍵字產生對象，而是通過對象複製來實現的模式】


public class Mail implements Cloneable{
    private String receiver;
    private String subject;
    private String appellation;
    private String context;
    private String tail;

    @Override
    public Mail clone(){
        //Mail mail = new Mail();
        Mail mail = null;
        try {
            mail = (Mail)super.clone();
        } catch (CloneNotSupportedException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }
        return mail;
    }
}

原型模式的核心是一個clone()方法，通過該方法進行對象的拷貝，java提供了Cloneable介面來標識這個對象是可拷貝的，該介面中沒有任何方法和屬性，僅僅是一個標識，在JVM中具有這個標記的對象才可能被拷貝。而重寫clone()方法即可從"可能被拷貝"-->"可以被拷貝"。

原型模式的優點：

  • 性能優良：原型模式是在記憶體二進位流的拷貝，要比直接new一個對象性能好很多，特別是在迴圈體內產生大量對象時，更能體現其優點
  • 逃避構造函數約束：既是優點也是缺點，直接在記憶體中拷貝，構造函數不會被執行。減少了約束。



使用場景：

  • 資源優化場景：類初始化需要消耗非常多的資源，包括數據、硬碟等
  • 性能和安全要求的場景：通過new產生一個對象需要非常繁瑣的數據準備或訪問許可權，則可以使用原型模式
  • 一個對象多個修改者的場景：一個對象需要提供給其他對象訪問，而且各個調用者可能都需要修改其值時，可以考慮原型模式拷貝多個對象供調用者使用


實際項目中很少單獨使用原型模式，一般和工廠方法模式一起出現，通過clone方法創建一個對象，然後由工廠方法提供給調用者。


註意事項：

  • 構造函數不會被執行

  • 深拷貝/淺拷貝
    淺拷貝

    public class Thing implements Cloneable{
private ArrayList<String> arrayList = new ArrayList<String>();
@Override
protected Thing clone(){
    Thing thing = null;
    try {
        thing = (Thing)super.clone();
    } catch (CloneNotSupportedException e) {
        // TODO Auto-generated catch block
        e.printStackTrace();
    }
    return thing;
}
public void setValue(String value){
    this.arrayList.add(value);
}
public ArrayList<String> getValue(){
    return this.arrayList;
}
public static void main(String[] args) {
    Thing thing = new Thing();
    thing.setValue("張三");
    Thing cloneThing = thing.clone();
    cloneThing.setValue("李四");
    System.out.println(thing.getValue());
    //結果【張三，李四】
}
}

    java做了一個偷懶的拷貝動作，Object類提供的方法clone只是拷貝本對象，其對象內部的數組、引用對象等都不拷貝，還是指向原生對象內部的元素地址，這種拷貝就是淺拷貝。
    兩個對象共用了一個私有變數，大家都能對其進行修改，這是非常不安全的方式。
    但String類型不會帶來淺拷貝的問題，內部的數組和引用對象才不拷貝，其他的原始類型(int/long/char)等都會被拷貝，但對於String，java就希望你把它認為是基本類型，它是沒有clone方法的，處理機制也比較特殊，通過字元串池(stringpool)在需要的時候才在記憶體中創建新的字元串。
    註意：使用原型模式時，引用的成員變數必須滿足兩個條件才不會被拷貝，類的成員變數，而不是方法內變數 ；必須是一個可變的引用對象，而不是一個原始類型或不可變對象；

    深拷貝

      @Override
protected Thing clone(){
    Thing thing = null;
    try {
        thing = (Thing)super.clone();
        //增加一下一行代碼
        thing.arrayList = (ArrayList<String>) this.arrayList.clone();
    } catch (CloneNotSupportedException e) {
        // TODO Auto-generated catch block
        e.printStackTrace();
    }
    return thing;
}

    僅增加一行，對私有的類變數進行獨立的拷貝。
    該方法實現了完全的拷貝，兩個對象之間沒有任何瓜葛了，這種拷貝就是深拷貝。
    深拷貝還有一種實現方式就是通過自己寫二進位流來操作對象，然後實現對象的深拷貝。

    註意：深拷貝和淺拷貝建議不要混合使用，特別是涉及類的繼承時，父類有多個引用的情況就非常複雜了，建議深/淺拷貝分開實現。

  • clone 與 final
    對象的clone與對象內的final關鍵字是有衝突的，例如上面的慄子若做一些簡單的修改
    private final ArrayList<String> arrayList = new ArrayList<String>();，則會爆出編譯錯誤，final類型無法切換引用，所以實現clone時是不能存在final關鍵字的。


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • DDD理論學習系列（9）-- 領域事件
    "DDD理論學習系列——案例及目錄" 1. 引言 A domain event is a full fledged part of the domain model, a representation of something that happened in the domain. Ignore ...
  • 設計模式總綱
    設計模式分類 設計模式是一套被反覆使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結。使用設計模式是為了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。主流的設計模式有23種，總體來說可以分為三大類 創建型模式(5) 工廠方法模式（Factory Pattern） 一種場景是希望工廠與產品的 ...
  • PowerShell~發佈你的mvc網站
    通過使用ps加上msbuild可以方便的編譯你的.net應用程式，並且可以把它發佈到你的磁碟上，部署非常方例！ 我們在c盤添加一個hello網站，解決方案名是hello.sln，它的網站是hello.csproj，現在使用這個腳本來生成這個網站和發佈這個網站！ 最後生成的網站結果為 這個功能對於自動 ...
  • 網頁靜態化技術
    靜態頁面：純html頁面 動態頁面：內容存在資料庫中，根據要求顯示，url中以？ &顯示不同的參數 偽靜態：僅僅是對靜態頁面的重寫，不能讓動態頁面靜態化。搜索引擎不會認為偽靜態就是HTML文檔。其次，偽靜態可取，但應把重心放在去除冗餘參數、規範URL、儘可能的避免 重覆頁上。 舉例說明: 這是一個動 ...
  • Unity應用架構設計(13)——日誌組件的實施
    對於應用程式而言，日誌是非常重要的功能，通過日誌，我們可以跟蹤應用程式的數據狀態，記錄Crash的日誌可以幫助我們分析應用程式崩潰的原因，我們甚至可以通過日誌來進行性能的監控。總之，日誌的好處很多，特別是對Release之後的線上版本進行異常的跟蹤。 日誌存儲的分類 在平常開發時，我們通常喜歡在De ...
  • 分散式系統中的必備良藥 —— 全局唯一單據號生成
    閱讀目錄 單據號是指什麼 和唯一ID的不同是什麼 為什麼需要全局唯一單據號生成程式 實現的方式有哪些 筆者推薦的方式 結語 一、單據號是指什麼 我們作為一個軟體系統，肯定到處充滿著各種單據，也必然需要有各種單據號與之對應。比如：電商行業的訂單號、支付流水號、退款單號等等。SCM的採購單號、進貨單號、 ...
  • Unity應用架構設計(12)——AOP思想的實踐
    想象一下，當程式所有的業務邏輯都完成的時候，你可能還來不及喘口氣，緊張的測試即將來臨。你的Boss告訴你，雖然程式沒問題，但某些方法為什麼執行這麼慢，性能堪憂。領會了Boss的意圖之後，漫長的排查問題開始了。你會寫日誌，或者是其他工具來追蹤原因。那麼如何以一種優雅的形式，並且不侵入業務代碼的形式來跟 ...
  • Spring Batch框架流程的簡單介紹
    Spring Batch流程介紹： 上圖描繪了Spring Batch的執行過程。說明如下： 每個Batch都會包含一個Job。Job就像一個容器，這個容器里裝了若幹Step，Batch中實際幹活的也就是這些Step，至於Step乾什麼活，無外乎讀取數據，處理數據，然後將這些數據存儲起來(ItemR ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發（一）：使用.NET MAUI開發第一個安卓APP
    移動開發（一）：使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說，近來想嘗試開發一款安卓APP，考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP，畢竟是使用Visual Studio開發工具，使用起來也比較的順手，結合微軟官方的教程進行了安卓 ...
  • wpf ToggleButton選中效果和一個登錄界面
    前言 QuestPDF 是一個開源 .NET 庫，用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫，它徹底改變了我們生成 PDF 文檔的方 ...
  • 彈幕樹洞項目功能新增篇
    項目地址 項目後端地址： https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址： ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址： http://tree ...
  • 第27篇 sqlserver2022詳細安裝步驟
    話不多說，直接開乾 一.下載 1.官方鏈接下載： https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe，運行開始下載SQL server； 二. ...
  • .NET 開源高性能 MQTT 類庫
    前言 隨著物聯網（IoT）技術的迅猛發展，MQTT（消息隊列遙測傳輸）協議憑藉其輕量級和高效性，已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫，為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog文檔翻譯系列（六） - 可用的接收器、增強器、格式化輸出
    Serilog支持多種接收器用於日誌存儲，增強器用於添加屬性，LogContext管理動態屬性，支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項，適用於不同需求。 ...
  • 警惕 Visual Studio 屬性求值副作用導致邏輯不符合預期
    目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據，爬取信息時需要模擬瀏覽器行為，否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下： 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • [使用目前最新版]HybridCLR6.9.0+YooAsset2.2.4實現純C# Unity熱更新方案 (一)
    1.前言 什麼是熱更新 游戲或者軟體更新時，無需重新下載客戶端進行安裝，而是在應用程式啟動的情況下，在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR，Xlua，ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles，Addressable， ...
  • 在 ASP.NET Core Web API 中使用操作篩選器統一處理通用操作
    本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺，其實像阿裡雲，騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後，它會送 ...
  • 第28篇 如何.net中實現高效可靠數據同步api
    通過以下方式可以高效，並保證數據同步的可靠性 1.API設計 使用RESTful設計，確保API端點明確，並使用適當的HTTP方法（如POST用於創建，PUT用於更新）。 設計清晰的請求和響應模型，以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證，確保接收到的數據符合預期格 ...
所有分類