這次是系列的第12篇 主題是原型模式(Prototype Pattern) 原型模式 一種創建型設計模式，它允許通過複製現有的物件來創建新物件，而不是通過實例化來生成物件。 這種模式適用於創建成本高昂或代價大的物件，通過複製來提升性能或簡化物件創建過程。 原型模式的核心思想是：利用已有物件作為模板進行複製，快速創建新物件。 結構:

這次是本系列的第11篇 主題是代理模式(Proxy Pattern) 代理模式 代理模式(Proxy Pattern) 一種結構型設計模式，它為目標物件提供了一個代理物件，代理物件控制對目標物件的訪問。 代理模式的主要目的是在不改變目標物件的前提下，通過代理物件來對目標物件的訪問進行控制或增強功能。 結構:

最近使用Unreal進行開發 載入用魔法小卡換來的資源時，發現貼圖沒辦法正確顯示 研究一下才發現是沒有開啟虛擬紋理(Virtual Texture)這個技術 虛擬紋理 Virtual Texture 那什麼是虛擬紋理? 基本上蠻複雜的 簡單來說，傳統的紋理(texture)處理需要將全部紋理全部載入到顯存(VRAM)中 但Virtual Texture允許只載入場景中實際需要的部分(Texture Tiles)，大大降低顯存需求。

這次是本系列的第10篇 主題是範本方法模式(Template Method Pattern) 範本方法模式 範本方法模式(Template Method Pattern) 一種行為型設計模式，它定義了一個操作中的演算法框架，並且允許子類去改變特定步驟的實現，而不改變該演算法的結構。 這種模式的主要目的是固定流程，但允許部分步驟的實現細節可以在子類中改變，以實現靈活的擴展和代碼復用。 範本方法模式的核心思想 範本方法模式涉及一個包含範本方法的基類，這個範本方法通常會定義一個操作的步驟順序，並且調用一些抽象方法或鉤子方法

這次是這系列的第9篇 主題是建造者模式(Builder Pattern) 建造者模式 一種創建型設計模式，它將一個複雜物件的構造過程與其表示分離，使得同樣的構建過程可以創建不同的表示。 建造者模式特別適合用於創建包含多種屬性或配置的複雜對象，並且允許對創建過程進行更靈活的控制。 建造者模式結構 產品(Product):

本系列的第8篇 這次是命令模式(Command Pattern) 命令模式 一種行為型設計模式，它將請求封裝成一個命令物件，從而使得不同的請求可以參數化和排程執行。 這種模式能夠讓系統支持可撤銷操作、日誌記錄、排程等功能。 在命令模式中，請求的發起者與具體的執行者分離，通過封裝請求（即命令物件），可以更靈活地管理請求的執行。 這種模式常見於需要執行操作排程或撤銷的情境中，例如多重操作的撤銷、事務處理、任務隊列等。

本系列的第7篇 這次是觀察者模式(Observer Pattern) 觀察者模式 一種行為型設計模式，它定義了一種一對多的依賴關係，即當一個物件（稱為「主題」或「被觀察者」）的狀態發生改變時 所有依賴它的物件（稱為「觀察者」）都會自動得到通知並更新。 觀察者模式的結構 主題 / 被觀察者(Subject):

本系列的第6篇 這次是裝飾器模式(Decorator Pattern) 裝飾器模式 一種結構型設計模式，它允許你動態地為物件添加新的行為或功能，而無需改變原始類別的定義。 核心思想是將功能封裝在不同的裝飾類別中，並通過堆疊或組合這些裝飾來靈活地擴展物件的行為。 假設我想實作某個遊戲攻擊系統 你的攻擊在一般狀況下是沒有屬性的，傷害也不高 但你可以透過其他機制為攻擊增加屬性、攻擊力，甚至是多重屬性

本系列的第五篇 這次是單例模式(Singleton) 單例模式 一種創建型設計模式，它確保一個類別在整個應用程序中只能有一個實體，並提供一個全局訪問點來存取該實體。 適合用在需要確保系統中某個類別只能存在一個實體的場景，例如： 日誌管理：應用程式中的日誌工具通常應該是單一的，讓整個系統都能共享同一個日誌實體。 配置管理：一個應用程式的配置通常只應該被建立一次，所有的模組共享相同的配置實體。

系列第四篇 練習的是策略模式(Strategy Pattern) 策略模式 一種行為型設計模式，它允許定義一系列可互換的演算法或策略，並讓客戶端在運行時可以自由選擇使用哪一種策略，而無需修改使用它們的代碼。 策略模式的核心思想是將演算法的定義與使用分開，將不同的演算法封裝在獨立的類別中，並且可以在運行時根據需要切換這些演算法。 假設我正在玩一款射擊遊戲 有把神奇的槍接受各種口徑的子彈

本系列的第三篇 這次是抽象工廠模式(Abstract Factory) 抽象工廠模式 一個工廠的工廠，提供一個介面來創建一系列相關或依賴的物件，而無需指定具體的類別。 此模式的擴展性最強，可以更方便地管理不同系列的物件。 from abc import ABC, abstractmethod class CPU(ABC):

這個系列的第二篇 改寫的是工廠方法模式(Factory Method Pattern) 工廠方法模式 定義一個抽象工廠接口，讓具體的子類別決定要創建哪一種物件。 子類別可以自行決定要創建的物件類型。 優點是遵循了開閉原則，添加新類別不需要修改現有的程式碼。 from abc import ABC, abstractmethod

這次要來寫設計模式系列 但不會以教學為主，而是以自己學習的結果為主 會簡短的提到每個模式的定義 接著以Python作改寫 親自改寫過應該會理解的透徹一點 簡易工廠模式 / 靜態工廠模式 由一個工廠類別負責根據不同的條件返回不同類別的物件。 缺點是違反開閉原則（OCP，Open/Closed Principle），每次增加新類別都需要修改工廠的邏輯。

前言 前陣子在工作上需要將後端Flask API Server與前端React進行串接 查了一下發現中文資料並不多，且範例程式碼有點舊或是不完善 所以打算寫一篇文章來做個紀錄 正文 這篇架設你對Flask與React有一定基礎 本篇會著重在前後端串接的實作 所以一些基礎教學就不會再說明

在寫搶票程式的過程中 有遇到處理圖形驗證碼的問題 此時需要先將圖片抓下來, 再透過openCV, numpy, 以及OCR等技術將文字給輸出 然而在windows上, 做這件事情會有點複雜 所以將過程記錄下來 先附上相關資訊 OS: Windows 10 22H2