2023-12-10
Dependency Injection 觀摩筆記 (DI & IOC)
觀摩 `Blazored/LocalStorage` 關於 Interface 設計與 Dependency Injection 的使用方式，從真實案例學習使用 Dependency Injection 🙂
#DesignPattern 所有符合的文章
顯示全部 0/0 篇文章
2021-06-16
Dependency Injection 初探筆記 (DI & IOC)
初探依賴注入 Denpendency Injection Pattern(DI) 與控制反轉 Inversioin of Control (IOC) 設計模式。
2020-07-17
重溫《深入淺出設計模式》心得整理 (Book Review of Head First Design Pattern, Summary)
將近三週的時間，將近完成重溫進度的 90 %，在最後 Summary 各模式的回顧並且筆記書中所提及的 OOP 原則，並紀錄書中尚未詳細介紹的模式，留待之後繼續實踐。同時也謹記書中最後的提醒：設計模式作為一種在一般性的情境、目標與解決方案下所被發現的結構，模式的使用並不是絕對與唯一，模式背後的 OOP 原則如果就能夠精準且保有彈性的解決問題，未必要加入模式讓專案變得複雜。 之後的學習規劃不以模式本身為主，而是進入 MVC 的框架，從框架的原始碼中發現設計模式，用設計模式理解 MVC 框架，讓兩者相輔相成。
2020-07-10
重溫《深入淺出設計模式》外觀模式 (Book Review of Head First Design Pattern, Facade Pattern)
外觀模式就是將眾多的類別 (整體系統中的一部分，例如整體是播放電影系統與系統部分類別則包括電視機、擴大機、音響、電腦的關係) 利用合成產生一個外觀類別，並令 Client 與外觀類別互動，取代 Client 直接與眾多的類別互動，有使用類別 (表象模式) 封裝類別 (系統的部分) 的概念。
2020-07-08
重溫《深入淺出設計模式》狀態模式 (Book Review of Head First Design Pattern, State Pattern)
狀態模式和策略模式師出同門，兩者在 UML 的表示上有相同的結構，同樣是利用執行期實作相同介面的不同類別的方法，以多型的方式精簡原本需要用 if else 邏輯來控制的程式流程。兩者的關鍵差別在於使用上的意圖，狀態模式是將物件的狀態封裝為類別，並藉由類別的轉換從而多型地調用方法；策略模式則是在執行期使用依據實作相同介面的不同類別，使用其專有的演算邏輯並避免掉繼承關係所衍生的維護困難。
2020-07-07
重溫《深入淺出設計模式》合成模式 (Book Review of Head First Design Pattern, Composite Pattern)
合成模式就是將類別建構為樹狀的關係，於是樹資料結構的階層關係、遞迴走訪便可以運用在設計系統上。同時合成模式可以與反覆器做結合，客製出強大的類別，保持新增的彈性同時也兼具走訪的便利。
2020-07-07
重溫《深入淺出設計模式》反覆器模式 (Book Review of Head First Design Pattern, Iterator Pattern)
反覆器已經被實踐在許多當代的語言之中，作為集合類型的低階類別所使用。以往並沒有特別感受到 Iterator 的美好，只覺得高階的語法 (python) 方便好用，而有時候得到物件回傳 Iterator 反而不知所措 (例如 Beautiful Soup)。但重溫反覆器模式後，才曉得作為底層的反覆器有多重要，同時理解它也有助於自行實踐整合不同型別的集合類別進行迭代。
2020-07-03
重溫《深入淺出設計模式》轉接器模式 (Book Review of Head First Design Pattern, Adapter Pattern)
轉接器模式常與表象模式進行比較，從使用上的觀點來看，前者是為了將類別能夠配合多型的方法使用，將目標類別以介面的方式，實作一個轉接器來轉換被既有的類別來達成；表象模式則是將龐雜的類別包裝成簡易的介面，讓使用者與龐雜的類別保持低耦合、最小知識，同時易於使用。
2020-07-02
重溫《深入淺出設計模式》命令模式 (Book Review of Head First Design Pattern, Command Pattern)
命令模式、外觀模式，乍看之下有些相似，但從模式的意義上的分別兩者就可以感受到不同。命令模式是將命令(要求、需求)封裝成物件，並且讓接受命令者與命令的執行職責拆分，類似餐廳點餐從老闆邊接受客人點餐、邊準備料理分為餐廳前台與餐廳後台，同時命令模式可以將命令與執行時間分隔，延後或者指定執行命令的時間；外觀模式則是將繁雜的類別方法，透過一個簡化的控制類別封裝複雜的演算邏輯，對使用者而言僅需要一個方法就能完成所有關聯的步驟。
2020-06-30
重溫《深入淺出設計模式》工廠模式 (Book Review of Head First Design Pattern, Factory Pattern)
工廠是物件實體化的工廠，在實體化衍生類別的時候，如果演算邏輯相當複雜或者有改變的需求，可以將其抽出，依需求的情境分別以最基本的簡單工廠包裝生產邏輯，進階的將生產的方法以衍生類別包裝實作，以工廠方法時做，或者更進階地將相同主題類別加以包裝，並以蘊含工廠方法的方式多型地完成生產的工作。
2020-06-29
重溫《深入淺出設計模式》裝飾者模式 (Book Review of Head First Design Pattern, Decorator Pattern)
以前第一次看到 Python 的 Decorator 時滿滿的黑人問號，後來有機會接觸裝飾者模式才豁然開朗，但也沒有深究，甚至沒有真的用過 Decorator。但最近重溫才發現其實裝飾者模式和 Python 的 Decorator 並不是完全的等號。Python 的 Decorator 更像是一種語法糖，利用 Python 函式 first class 的特性，能夠有更方便包裝函式的語法，可以為函式前後加入邏輯並且重利用程式碼。而要利用 Python 的 Decorator 也可以實踐 Decorator Pattern ，只是兩者並不是相等的，一個是語法模式，但背後有 Pattern 的精神；另一個則是 Pattern。
2020-06-29
重溫《深入淺出設計模式》觀察者模式 (Book Review of Head First Design Pattern, Observer Pattern)
設計模式不會讓直觀上開發速度變得更快，反而在開發時會需要夠多的時間進行思考，然後才動手。但它的效益應該是當要維護、要擴充時，才能夠體現的，因為有良好的設計模式，程式碼的架構是充滿彈性且易於回應需求的，相較快速完成的架構可能缺少擴充的彈性，在面對需求時只能砍掉重練，或者是提心吊膽的修改程式碼害怕牽一髮動全身。無疑地如果在有需求變動的情境，使用設計模式先苦後甘是最好的選擇。
2020-06-28
重溫《深入淺出設計模式》策略模式 (Book Review of Head First Design Pattern, Strategy Pattern)
設計模式是很需要開發經驗來輔助學習的，一兩年前就曾經翻閱過這本書，只是當時對物件導向的體會仍是懵懂，而僅有物件導向的知識也無法自然的學會設計模式的使用，因為設計模式需要程式開發的經驗累積，在開發中必須實際使用物件導向，同時需要對話、討論，並且實際體驗過擴充、維護的痛楚，才能歸結出設計模式。而直接學習設計模式儼然就是快速增長物件導向的設計功力，但也因為缺少了實際感受到設計模式美好的過程，所以學習容易流於浮光掠影的記憶。 這次的學習除了閱讀本身，更強調實作，除了重新詮釋閱讀素材的案例並改寫成 C# Code外，也將模式前後的差別書寫成部落格，期待讓學習更深植腦中，能夠設計模式真正的成為自己的一部分。