Builder（建造者模式）
目錄 design pattern 以java 為例 特點將一個複雜對象的構建過程封裝起來，使得同樣的構建過程可以創造不同的表示，簡單講就是 把複雜的都包成api 舉例反例Person 裡面包括多個屬性，但如果其中有幾個參數是非必填，則 缺乏彈性：如果Person的某些屬性是可選的，使用這種重載構造函數的方式會導致必須創建多個構造函數來支持不同的參數組合。 可讀性差：隨著參數數量的增加，調用
qdrant 向量資料庫
目前常見的向量資料庫有以下，看中qdrant 的支援跟易用性都不錯，而且是用rust寫的，就來使用看看 特性/資料庫 Pinecone Weaviate Milvus Qdrant Chroma Elasticsearch PGvector 是否為開源 ❌ ✅ ✅ ✅ ✅ ❌ ✅ 自我託管 ❌ ✅ ✅ ✅ ✅ ✅ ✅ 雲管理 ✅ ✅ ✅ ✅ ❌ ✔️ ✅ 專為向量
flowise low code 的 RAG系統
自上篇LlamaIndex 自訂義RAG 系統如果覺得寫程式更改很麻煩，flowise這個開源專案很好的結合了工作流 跟low code應用 官方部屬文件githubhttps://github.com/FlowiseAI/Flowise docshttps://docs.flowiseai.com/ 部屬方法 clone public repo 1git clone https://gith
依賴反轉原則（Dependency Inversion Principle，DIP）
目錄 design pattern 以java 為例 要素 高階模組不應該依賴於低階模組。兩者都應該依賴於抽象。 抽象不應該依賴於細節。細節應該依賴於抽象。 範例違反的例子Notifiaction 這個class 直接把email 包在裡面做使用，未來如果要加簡訊或是其他傳訊方式就會無法解耦，屬於高階模組依賴於低階的例子 123456789101112131415161718class Emai
接口隔離原則（Interface Segregation Principle, ISP)
目錄 design pattern 以java 為例 解釋SOLID原則之一，由羅伯特·C·馬丁（Robert C. Martin）提出。ISP強調應當將“胖接口”（fatinterfaces，即那些擁有太多方法的接口）拆分成更小、更專注的接口，這樣可以避免類別依賴它們不需要的接口，從而降低系統的耦合度，提高其靈活性和可維護性。 特點 降低耦合度：通過拆分接口，類別之間的依賴關係變得更加清晰，減少
單一責任原則（Single Responsibility Principle, SRP）
目錄 design pattern 以java 為例 單一責任原則（Single Responsibility Principle, SRP）描述一個class應該只負責一件事 範例我們現在要做員工的報表，所以可以將員工跟報表拆分成不同class，如果員工內容有變，輸出報表則不用變 Employee1234567891011121314151617class Employee {
開放封閉原則( Open Closed Principle, OCP)
目錄 design pattern 以java 為例 開放封閉原則 (OCP: Open Closed Principle)通常簡稱為 SOLID 原則中的 “O”。這個原則指出軟件實體（類、模塊、函數等）應該對擴展開放，對修改封閉。 實現方式 interface abstract code 翻立基礎資料加設現在要做一個商品的filter, 並且依顏色形狀等做分類，我們會有基礎class 12
design pattern 以java 為例
Design pattern軟體工程中一種對於常見問題的解決方案的標準化描述，簡單講就是人家想好的高效範本 分類SOLID原則SOLID原則是面向對象設計和程式開發中的一組五個基本原則，旨在促進軟體的可讀性、可維護性和擴展性 單一職責原則（Single Responsibility Principle, SRP） 每個類應該只有一個引起它變化的原因。這個原則強調，一個類應該專注於單一的職責或功能
