標籤: 台北網頁設計

引言

UDP是一個簡單的面向數據報的運輸層協議

UDP不提供可靠性，它把應用程序傳給IP層得數據發送出去，不保證它們能達到目的地

UDP首部

端口號表示發送進程和接受進程。

UDP長度字段指的是UDP首部和UDP數據的字節長度，該字段最小值為8字節，

UDP長度是全長減去IP首部的長度

UDP檢驗和是一個端到端的檢驗和。它由發送端計算，然後由接收端驗證。其目的是為了發現UDP首部和數據在發送端到接收端之間發生的任何改動。

最大UDP數據報長度

理論上，IP數據報的最大長度是65535字節，這是由IP首部（圖3-1）16比特總長度字段所限制的。去除20字節的IP首部和8個字節的UDP首部，UDP數據報中用戶數據的最長長度為65507字節。但是，大多數實現所提供的長度比這個最大值小。

UDP校驗和

UDP和TCP在首部中都有覆蓋它們首部和數據的檢驗和。UDP的檢驗和是可選的，而TCP的檢驗和是必需的。

儘管UDP檢驗和的基本計算方法與我們在3.2節中描述的IP首部檢驗和計算方法相類似（16 bit字的二進制反碼和），但是它們之間存在不同的地方。首先，UDP數據報的長度可以為奇数字節，但是檢驗和算法是把若干個16 bit字相加。解決方法是必要時在最後增加填充字節0，這隻是為了檢驗和的計算（也就是說，可能增加的填充字節不被傳送）。

其次，UDP數據報和TCP段都包含一個12字節長的偽首部，它是為了計算檢驗和而設置的。偽首部包含IP首部一些字段。其目的是讓UDP兩次檢查數據是否已經正確到達目的地（例如，IP沒有接受地址不是本主機的數據報，以及IP沒有把應傳給另一高層的數據報傳給UDP）。UDP數據報中的偽首部格式如圖11-3所示。

在該圖中，我們特地舉了一個奇數長度的數據報例子，因而在計算檢驗和時需要加上填充字節。注意，UDP數據報的長度在檢驗和計算過程中出現兩次。

如果檢驗和的計算結果為0，則存入的值為全1（65535），這在二進制反碼計算中是等效的。如果傳送的檢驗和為0，說明發送端沒有計算檢驗和。

如果發送端沒有計算檢驗和而接收端檢測到檢驗和有差錯，那麼UDP數據報就要被悄悄地丟棄。不產生任何差錯報文（當IP層檢測到IP首部檢驗和有差錯時也這樣做）。

UDP檢驗和是一個端到端的檢驗和。它由發送端計算，然後由接收端驗證。其目的是為了發現UDP首部和數據在發送端到接收端之間發生的任何改動。

這個系列主要是對自己讀TCP/IP詳解 卷一 協議的筆記，推薦看完以後去閱讀一下這本又臭又厚的書

电子書的鏈接地址http://www.52im.net/topic-tcpipvol1.html

感謝這位站長的開源 

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※回頭車貨運收費標準

※產品缺大量曝光嗎?你需要的是一流包裝設計!

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※推薦評價好的iphone維修中心

※教你寫出一流的銷售文案?

作者：小傅哥
博客：https://bugstack.cn

沉澱、分享、成長，讓自己和他人都能有所收穫！

一、前言

對於代碼你有編程感覺嗎

很多人寫代碼往往是沒有編程感覺的，也就是除了可以把功能按照固定的流程編寫出流水式的代碼外，很難去思考整套功能服務的擴展性和可維護性。尤其是在一些較大型的功能搭建上，比較缺失一些駕馭能力，從而導致最終的代碼相對來說不能做到盡善盡美。

江洋大盜與江洋大偷

兩個本想描述一樣的意思的詞，只因一字只差就讓人覺得一個是好牛，一個好搞笑。往往我們去開發編程寫代碼時也經常將一些不恰當的用法用於業務需求實現中，當卻不能意識到。一方面是由於編碼不多缺少較大型項目的實踐，另一方面是不思進取的總在以完成需求為目標缺少精益求精的工匠精神。

書從來不是看的而是用的

在這個學習資料幾乎爆炸的時代，甚至你可以輕易就獲取幾個T的視頻，小手輕輕一點就收藏一堆文章，但卻很少去看。學習的過程從不只是簡單的看一遍就可以，對於一些實操性的技術書籍，如果真的希望學習到知識，那麼一定是把這本書用起來而絕對不是看起來。

二、開發環境

1. JDK 1.8
2. Idea + Maven
3. 涉及工程三個，可以通過關注公眾號：bugstack蟲洞棧，回復源碼下載獲取(打開獲取的鏈接，找到序號18)

三、裝飾器模式介紹

初看上圖感覺裝飾器模式有點像俄羅斯套娃、某眾汽車，而裝飾器的核心就是再不改原有類的基礎上給類新增功能。不改變原有類，可能有的小夥伴會想到繼承、AOP切面，當然這些方式都可以實現，但是使用裝飾器模式會是另外一種思路更為靈活，可以避免繼承導致的子類過多，也可以避免AOP帶來的複雜性。

你熟悉的場景很多用到裝飾器模式

new BufferedReader(new FileReader(""));，這段代碼你是否熟悉，相信學習java開發到字節流、字符流、文件流的內容時都見到了這樣的代碼，一層嵌套一層，一層嵌套一層，字節流轉字符流等等，而這樣方式的使用就是裝飾器模式的一種體現。

四、案例場景模擬

在本案例中我們模擬一個單點登錄功能擴充的場景

一般在業務開發的初期，往往內部的ERP使用只需要判斷賬戶驗證即可，驗證通過後即可訪問ERP的所有資源。但隨着業務的不斷髮展，團隊里開始出現專門的運營人員、營銷人員、數據人員，每個人員對於ERP的使用需求不同，有些需要創建活動，有些只是查看數據。同時為了保證數據的安全性，不會讓每個用戶都有最高的權限。

那麼以往使用的SSO是一個組件化通用的服務，不能在裏面添加需要的用戶訪問驗證功能。這個時候我們就可以使用裝飾器模式，擴充原有的單點登錄服務。但同時也保證原有功能不受破壞，可以繼續使用。

1. 場景模擬工程

itstack-demo-design-9-00
└── src
    └── main
        └── java
            └── org.itstack.demo.design
                ├── HandlerInterceptor.java
                └── SsoInterceptor.java

• 這裏模擬的是spring中的類：HandlerInterceptor，實現起接口功能SsoInterceptor模擬的單點登錄攔截服務。
• 為了避免引入太多spring的內容影響對設計模式的閱讀，這裏使用了同名的類和方法，盡可能減少外部的依賴。

2. 場景簡述

2.1 模擬Spring的HandlerInterceptor

public interface HandlerInterceptor {

    boolean preHandle(String request, String response, Object handler);

}

• 實際的單點登錄開發會基於；org.springframework.web.servlet.HandlerInterceptor 實現。

2.2 模擬單點登錄功能

public class SsoInterceptor implements HandlerInterceptor{

    public boolean preHandle(String request, String response, Object handler) {
        // 模擬獲取cookie
        String ticket = request.substring(1, 8);
        // 模擬校驗
        return ticket.equals("success");
    }

}

• 這裏的模擬實現非常簡單隻是截取字符串，實際使用需要從HttpServletRequest request對象中獲取cookie信息，解析ticket值做校驗。
• 在返回的裏面也非常簡單，只要獲取到了success就認為是允許登錄。

五、用一坨坨代碼實現

此場景大多數實現的方式都會採用繼承類

繼承類的實現方式也是一個比較通用的方式，通過繼承后重寫方法，併發將自己的邏輯覆蓋進去。如果是一些簡單的場景且不需要不斷維護和擴展的，此類實現並不會有什麼，也不會導致子類過多。

1. 工程結構

itstack-demo-design-9-01
└── src
    └── main
        └── java
            └── org.itstack.demo.design
                └── LoginSsoDecorator.java

• 以上工程結構非常簡單，只是通過 LoginSsoDecorator 繼承 SsoInterceptor，重寫方法功能。

2. 代碼實現

public class LoginSsoDecorator extends SsoInterceptor {

    private static Map<String, String> authMap = new ConcurrentHashMap<String, String>();

    static {
        authMap.put("huahua", "queryUserInfo");
        authMap.put("doudou", "queryUserInfo");
    }

    @Override
    public boolean preHandle(String request, String response, Object handler) {
        // 模擬獲取cookie
        String ticket = request.substring(1, 8);
        // 模擬校驗
        boolean success = ticket.equals("success");

        if (!success) return false;

        String userId = request.substring(9);
        String method = authMap.get(userId);

        // 模擬方法校驗
        return "queryUserInfo".equals(method);
    }

}

• 以上這部分通過繼承重寫方法，將個人可訪問哪些方法的功能添加到方法中。
• 以上看着代碼還算比較清晰，但如果是比較複雜的業務流程代碼，就會很混亂。

3. 測試驗證

3.1 編寫測試類

@Test
public void test_LoginSsoDecorator() {
    LoginSsoDecorator ssoDecorator = new LoginSsoDecorator();
    String request = "1successhuahua";
    boolean success = ssoDecorator.preHandle(request, "ewcdqwt40liuiu", "t");
    System.out.println("登錄校驗：" + request + (success ? " 放行" : " 攔截"));
}

• 這裏模擬的相當於登錄過程中的校驗操作，判斷用戶是否可登錄以及是否可訪問方法。

3.2 測試結果

登錄校驗：1successhuahua 攔截

Process finished with exit code 0

• 從測試結果來看滿足我們的預期，已經做了攔截。如果你在學習的過程中，可以嘗試模擬單點登錄並繼承擴展功能。

六、裝飾器模式重構代碼

接下來使用裝飾器模式來進行代碼優化，也算是一次很小的重構。

裝飾器主要解決的是直接繼承下因功能的不斷橫向擴展導致子類膨脹的問題，而是用裝飾器模式后就會比直接繼承顯得更加靈活同時這樣也就不再需要考慮子類的維護。

在裝飾器模式中有四個比較重要點抽象出來的點；

1. 抽象構件角色(Component) – 定義抽象接口
2. 具體構件角色(ConcreteComponent) – 實現抽象接口，可以是一組
3. 裝飾角色(Decorator) – 定義抽象類並繼承接口中的方法，保證一致性
4. 具體裝飾角色(ConcreteDecorator) – 擴展裝飾具體的實現邏輯

通過以上這四項來實現裝飾器模式，主要核心內容會體現在抽象類的定義和實現上。

1. 工程結構

itstack-demo-design-9-02
└── src
    └── main
        └── java
            └── org.itstack.demo.design
                ├── LoginSsoDecorator.java
                └── SsoDecorator.java

裝飾器模式模型結構

• 以上是一個裝飾器實現的類圖結構，重點的類是SsoDecorator，這個類是一個抽象類主要完成了對接口HandlerInterceptor繼承。
• 當裝飾角色繼承接口後會提供構造函數，入參就是繼承的接口實現類即可，這樣就可以很方便的擴展出不同功能組件。

2. 代碼實現

2.1 抽象類裝飾角色

public abstract class SsoDecorator implements HandlerInterceptor {

    private HandlerInterceptor handlerInterceptor;

    private SsoDecorator(){}

    public SsoDecorator(HandlerInterceptor handlerInterceptor) {
        this.handlerInterceptor = handlerInterceptor;
    }

    public boolean preHandle(String request, String response, Object handler) {
        return handlerInterceptor.preHandle(request, response, handler);
    }

}

• 在裝飾類中有兩個重點的地方是；1)繼承了處理接口、2)提供了構造函數、3)覆蓋了方法preHandle。
• 以上三個點是裝飾器模式的核心處理部分，這樣可以踢掉對子類繼承的方式實現邏輯功能擴展。

2.2 裝飾角色邏輯實現

public class LoginSsoDecorator extends SsoDecorator {

    private Logger logger = LoggerFactory.getLogger(LoginSsoDecorator.class);

    private static Map<String, String> authMap = new ConcurrentHashMap<String, String>();

    static {
        authMap.put("huahua", "queryUserInfo");
        authMap.put("doudou", "queryUserInfo");
    }

    public LoginSsoDecorator(HandlerInterceptor handlerInterceptor) {
        super(handlerInterceptor);
    }

    @Override
    public boolean preHandle(String request, String response, Object handler) {
        boolean success = super.preHandle(request, response, handler);
        if (!success) return false;
        String userId = request.substring(8);
        String method = authMap.get(userId);
        logger.info("模擬單點登錄方法訪問攔截校驗：{} {}", userId, method);
        // 模擬方法校驗
        return "queryUserInfo".equals(method);
    }
}

• 在具體的裝飾類實現中，繼承了裝飾類SsoDecorator，那麼現在就可以擴展方法；preHandle
• 在preHandle的實現中可以看到，這裏只關心擴展部分的功能，同時不會影響原有類的核心服務，也不會因為使用繼承方式而導致的多餘子類，增加了整體的靈活性。

3. 測試驗證

3.1 編寫測試類

@Test
public void test_LoginSsoDecorator() {
    LoginSsoDecorator ssoDecorator = new LoginSsoDecorator(new SsoInterceptor());
    String request = "1successhuahua";
    boolean success = ssoDecorator.preHandle(request, "ewcdqwt40liuiu", "t");
    System.out.println("登錄校驗：" + request + (success ? " 放行" : " 攔截"));
}

• 這裏測試了對裝飾器模式的使用，通過透傳原有單點登錄類new SsoInterceptor()，傳遞給裝飾器，讓裝飾器可以執行擴充的功能。
• 同時對於傳遞者和裝飾器都可以是多組的，在一些實際的業務開發中，往往也是由於太多類型的子類實現而導致不易於維護，從而使用裝飾器模式替代。

3.2 測試結果

23:50:50.796 [main] INFO  o.i.demo.design.LoginSsoDecorator - 模擬單點登錄方法訪問攔截校驗：huahua queryUserInfo
登錄校驗：1successhuahua 放行

Process finished with exit code 0

• 結果符合預期，擴展了對方法攔截的校驗性。
• 如果你在學習的過程中有用到過單點登陸，那麼可以適當在裏面進行擴展裝飾器模式進行學習使用。
• 另外，還有一種場景也可以使用裝飾器。例如；你之前使用某個實現某個接口接收單個消息，但由於外部的升級變為發送list集合消息，但你又不希望所有的代碼類都去修改這部分邏輯。那麼可以使用裝飾器模式進行適配list集合，給使用者依然是for循環后的單個消息。

七、總結

• 使用裝飾器模式滿足單一職責原則，你可以在自己的裝飾類中完成功能邏輯的擴展，而不影響主類，同時可以按需在運行時添加和刪除這部分邏輯。另外裝飾器模式與繼承父類重寫方法，在某些時候需要按需選擇，並不一定某一個就是最好。
• 裝飾器實現的重點是對抽象類繼承接口方式的使用，同時設定被繼承的接口可以通過構造函數傳遞其實現類，由此增加擴展性並重寫方法里可以實現此部分父類實現的功能。
• 就像夏天熱你穿短褲，冬天冷你穿棉褲，雨天挨澆你穿雨衣一樣，你的根本本身沒有被改變，而你的需求卻被不同的裝飾而實現。生活中往往比比皆是設計，當你可以融合這部分活靈活現的例子到代碼實現中，往往會創造出更加優雅的實現方式。

八、推薦閱讀

• 1. 重學 Java 設計模式：實戰工廠方法模式(多種類型商品發獎場景)
• 2. 重學 Java 設計模式：實戰抽象工廠模式(替換Redis雙集群升級場景)
• 3. 重學 Java 設計模式：實戰建造者模式(裝修物料組合套餐選配場景)
• 4. 重學 Java 設計模式：實戰原型模式(多套試每人題目和答案亂序場景)
• 5. 重學 Java 設計模式：實戰橋接模式(多支付渠道「微信、支付寶」與多支付模式「刷臉、指紋」場景)
• 6. 重學 Java 設計模式：實戰組合模式(營銷差異化人群發券，決策樹引擎搭建場景)

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※別再煩惱如何寫文案,掌握八大原則!

※教你寫出一流的銷售文案?

※超省錢租車方案

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※產品缺大量曝光嗎?你需要的是一流包裝設計!

※回頭車貨運收費標準

前言

在周六發現了Linus去Google演講的一個視頻，當時還發了一條朋友圈：

有興趣的同學也可以去看看，一點兒也不無聊，在線看Linus大佬懟人

https://www.bilibili.com/video/BV1xb411A7ac?from=search&seid=4239535088233137638

朋友圈的評論有幾個人問我女朋友呢

我又恰好給我女朋友科普過什麼是Git，所以這篇文章就有了。

Git介紹

Git是幹啥用的？它是一個版本控制軟件。

Git這個玩意三歪曾經還給女朋友給科普過（三歪會經常給女朋友說點技術的東西，我也不知道她到底聽懂了沒有，反正她每次都說好像有點懂了）。

當時情況是這樣的，某一天她跟三歪說：我做的Excel還沒保存，電腦藍屏死機了，東西全丟了。

於是三歪說：這…我也沒怎麼用過Excel這類的軟件，要不看看你用的WPS或者Office？有沒有相關的備份功能或者說是自動保存？

三歪順手找了一下WPS是有備份（自動保存）功能的，時間什麼的要自己定義一下。

三歪還補了一句：這種情況要是在程序員的手上感覺發生的概率會低一點，程序員習慣會按ctrl+s。甚至有的時候，看着看着網頁還會按ctrl+s。不過像我們寫代碼的工具(IDEA)都不用自己手動保存了….

過了一會，她說藍屏之前做的東西找不回來了，沒設置自動保存。

三歪又感嘆一句：我們寫代碼還有版本控制的軟件，在這個過程中會記錄每次修改的內容，誰改了什麼東西。誰改錯了，誰要背鍋，一個都不能跑！

女朋友聽着三歪一頓亂吹，貌似也有點感興趣：“版本控制是什麼東西？這麼厲害的嗎？會計就經常要背鍋”

三歪：“其實也沒啥，就是我們一般寫代碼往往都是多人協作的。你們會計可能是每個人負責一張表(Excel)，然後把已完成好的表傳給下一個人。而寫代碼的不一樣，我們都是在同一個項目裡邊編寫的，不會單獨等着某個人做完了，其他的人再開始動手”

女朋友：“嗯？然後呢”

三歪：“你可以理解成，我們多個人會在同一個目錄下編寫代碼，裡邊可能會做更改或者添加文件的操作。項目組裡的所有人都可以對這個目錄修改，改完了我們會提交，然後發布上線系統。”

女朋友：“啥？你是不是偏題了？這跟發布上線系統有啥關係？”

三歪：“哦，我還是舉個例子吧。就比如我們寫論文的時候可能要對論文不斷修改，我們的修改是基於原有的基礎上改的”

三歪繼續補充：”因為我們怕在原來的基礎改錯了東西，沒法恢復，所以，我們可能會有多個「畢業論文」的文件。而我們寫代碼的時候本身就是「多人協作」的，修改是無法避免的，我們不希望有多個文件的產生，又希望能夠記錄每次更改的內容。“

三歪：”更改的內容指的就是：基於原有的基礎上更改了什麼，以及提交者是誰。這樣子，我們就沒法甩鍋了。說白了就是，我們能知道的文件被改了什麼，以及誰改了“。

三歪：“到這裏，有問題嗎？”

女朋友：“嗯，沒問題，你繼續”

三歪：“「每一次的修改」我們稱為一個版本，它能夠實現版本與版本之間的來回穿梭。打個比方，我有篇文章寫了一周，這期間有10個版本，我能隨意回到我想要的版本。所以它叫做版本控制軟件”

女朋友：“我大致聽懂了，大概就是每一次修改都會被記錄下來，然後你們就可以知道每一次版本修改了什麼，是誰改的，如果做錯了，可以通過這個軟件回到想要的版本”

三歪：“嗯，就是這個意思”

女朋友：“那我想問個問題，你一直提到的「多人協作」是在同一個目錄下對文件修改的，然後可以看到彼此改了什麼。那你是在你的電腦上改，你的同事是在他的電腦上改的，你們是怎麼看到彼此改了什麼？這現在有這麼厲害的東西了嗎？“

三歪：”哦~你的意思大概就是：我們又不聯網，怎麼知道對方改了什麼，是這個意思吧？“

女朋友：“嗯，是的”

三歪：“你的理解是沒錯的，我們之間不聯網，是沒辦法知道對方改了什麼的。我漏了一點沒說，我們在改到一定程度下（比如說這個功能我們做完了、也可能做得差不多了），我們會把當前版本提交到遠程倉庫上”

三歪繼續補充：“可以發現的是，提交到遠程倉庫后，即便我們電腦壞了，我們可以從遠程倉庫再把這份數據拉取下來。”

女朋友：“所以呢？遠程倉庫到我這聽起來就是一個備份的功能吧？你們怎麼知道對方改了什麼？”

三歪：“是這樣的，我們從遠程倉庫拉取代碼的時候除了會把有變動的代碼同步到自己的電腦上，還會把所有修改的記錄也同步到自己的電腦上。所以說，我們會知道彼此修改的內容。”

女朋友：”聽着很有用啊，我平時用的word和excel可以用這個軟件嗎？即便我電腦壞了，我還可以去『遠程倉庫』拿到上一次我提交的數據，並且還有你所說的『版本控制』功能。又能備份，又能知道每次修改了什麼，很好用啊！“

三歪：”很可惜，像你們那種工作場景，可能用不上，也可以說不太適合用“

女朋友：”為什麼？“

三歪：”之前我也想要用定時任務+GitHub的方式去保存我在本地寫的文章，發出來之後，被一頓噴。GitHub你可以簡單理解為就是那個遠程倉庫，定時任務我就是讓它隔一段時間就保存一次“

女朋友：”我聽明白了，你想要的是備份功能，對吧？為什麼被噴的呢？“

三歪：”他們說我瞎整，這每隔一段時間就提交到GitHub，網絡開銷可多大啊。然後給我列出一系列的產品，比如說：「堅果雲」「Dropbox」「OneDrive」等等“

女朋友：”那你怎麼不用？“

三歪：”我哪知道啊，有信息差的呢。反正當時覺得自己寫個定時任務實現了，就沒多想了。“

女朋友：”那你是真的菜“

三歪：”哦“

三歪：”除了上面說的自動同步，你們的word、excel在用我們的工具也沒法查到歷史的版本記錄“

女朋友：”為啥？你不是說你們寫代碼都可以的嗎？為什麼word和excel就沒法查？“

三歪：”我們寫代碼的文件類型都是屬於文本文件，而你的word、excel本質上屬於二進制文件，很難去比對每次修改的差異，所以不支持“

女朋友：”那聽你這樣說，在我的場景里這個「版本控制軟件」沒啥用啊，它不能記錄像Word、Excel這種文件每次版本的差異，要想用它做備份，還不如現有的雲產品。“

三歪：”嗯，是的。其實現在雲產品也能提供版本控制的功能了，你用它們就足夠了。還有一點很重要的是，它有學習成本，可不是每個人都會用的。“

女朋友：”聽你說了這麼多，好像雲產品就很行啊，為啥你們還要「偏執」去用你說的那東西？“

三歪：“主要是我們寫代碼時遇到的問題會更多，我們用的「版本控制軟件」會更加靈活，它支持的功能會更多。”

女朋友：“對了，你都說了這麼久了，你們用的那個軟件叫啥啊？”

三歪：“Git”

三歪瞎扯

其實本來想着直接講一下在工作中常用到的Git命令，但發現不太好寫（琢磨了很久

看三歪文章的人可能很多都是大學生，對Git本身了解可能就不太清楚，直接上Git的命令可能看不太懂，所以就分開了兩篇。

下一篇講一下三歪在工作中使用Git的糗事以及工作中是怎麼用Git的。

涵蓋Java後端所有知識點的開源項目（已有8K+ star）：

• GitHub
• Gitee訪問更快

我是三歪，一個想要變強的男人，感謝大家的點贊收藏和轉發，下期見。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※別再煩惱如何寫文案,掌握八大原則!

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※超省錢租車方案

※教你寫出一流的銷售文案?

※網頁設計最專業,超強功能平台可客製化

※產品缺大量曝光嗎?你需要的是一流包裝設計!

本文始發於個人公眾號：TechFlow，原創不易，求個關注

Input: S = "ADOBECODEBANC", T = "ABC"
Output: "BANC"

# 存儲區間內的字符
segement = {}
for i in range(n):
    segement[s[i]] += 1
    # 當滿足條件的時候移動區間左側
    while l <= i and satisified(segment):
        # 更新最佳答案
        if i - l + 1 < ans_len:
            ans_len = i - l + 1
            beg, end = l, i + 1
        # 彈出元素
  segement[s[l]] -= 1
        l += 1

class Solution:
    def minWindow(self, s: str, t: str) -> str:
        from collections import Counter, defaultdict
        # 通過Counter直接獲取T當中的字符構成
        counter = Counter(t)
        n, m = len(s), len(counter)
        l, beg, end = 0, 0, 0
        cur = defaultdict(int)
        matched = 0
        flag = False
        # 記錄合法的字符串的長度
        ans_len = 0x3f3f3f3f
        
        for i in range(n):
            if s[i] not in counter:
                continue
                
            cur[s[i]] += 1
            # 當數量匹配上的時候，matched+1
            if cur[s[i]] == counter[s[i]]:
                matched += 1
                
            # 如果已經找到了合法的區間，嘗試縮短區間的長度
            while l <= i and matched == m:
                if i - l + 1 < ans_len:
                    flag = True
                    beg, end = l, i+1
                    ans_len = i - l + 1
                    
                # 彈出左側元素
                c = s[l]
                if c in counter:
                    cur[c] -= 1
                    if cur[c] < counter[c]:
                        matched -= 1
                        
                l += 1

        
        return "" if not flag else s[beg: end]

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※教你寫出一流的銷售文案?

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※回頭車貨運收費標準

※別再煩惱如何寫文案,掌握八大原則!

※超省錢租車方案

※產品缺大量曝光嗎?你需要的是一流包裝設計!