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