重溫《深入淺出設計模式》合成模式 (Book Review of Head First Design Pattern, Composite Pattern)
合成模式就是將類別建構為樹狀的關係,於是樹資料結構的階層關係、遞迴走訪便可以運用在設計系統上。同時合成模式可以與反覆器做結合,客製出強大的類別,保持新增的彈性同時也兼具走訪的便利。
合成模式就是將類別建構為樹狀的關係,於是樹資料結構的階層關係、遞迴走訪便可以運用在設計系統上。同時合成模式可以與反覆器做結合,客製出強大的類別,保持新增的彈性同時也兼具走訪的便利。
反覆器已經被實踐在許多當代的語言之中,作為集合類型的低階類別所使用。以往並沒有特別感受到 Iterator 的美好,只覺得高階的語法 (python) 方便好用,而有時候得到物件回傳 Iterator 反而不知所措 (例如 Beautiful Soup)。但重溫反覆器模式後,才曉得作為底層的反覆器有多重要,同時理解它也有助於自行實踐整合不同型別的集合類別進行迭代。
從來沒有想過自行開發 Windows Service,一直以來都是在伺服器上直接執行 batch 或者經由工作排程器的方式執行想要達成的服務,但偶然契機下學習到 Windows Service 可以得到更多的便利性,同時藉由安裝 Topshelf 僅需要以 Console 開發上做延伸即可,非常實用。
轉接器模式常與表象模式進行比較,從使用上的觀點來看,前者是為了將類別能夠配合多型的方法使用,將目標類別以介面的方式,實作一個轉接器來轉換被既有的類別來達成;表象模式則是將龐雜的類別包裝成簡易的介面,讓使用者與龐雜的類別保持低耦合、最小知識,同時易於使用。
微軟因應新冠肺炎所造成的失業問題,經由分析 Linkedin 的資料後提出十種市場需要的專業,並且減免 Azure 證照的測驗費用,活動到 2020 年底以前。
命令模式、外觀模式,乍看之下有些相似,但從模式的意義上的分別兩者就可以感受到不同。命令模式是將命令(要求、需求)封裝成物件,並且讓接受命令者與命令的執行職責拆分,類似餐廳點餐從老闆邊接受客人點餐、邊準備料理分為餐廳前台與餐廳後台,同時命令模式可以將命令與執行時間分隔,延後或者指定執行命令的時間;外觀模式則是將繁雜的類別方法,透過一個簡化的控制類別封裝複雜的演算邏輯,對使用者而言僅需要一個方法就能完成所有關聯的步驟。
不同於以往覺得 Intellisense 就是一切的想法,Quick Action 以及 Code Snippet 重新塑造自己對於 Visual Studio 編輯程式碼過程的方法,原本一直覺得要花錢買 ReSharper 才能得到那種行雲流水的開發體驗,但 Visual Studio 2019 原生所支援的 Quick Action 就已經非常好用,本篇筆記用以紀錄如何以 Quick Action 以及 Code Snippet 來進行開發。
工廠是物件實體化的工廠,在實體化衍生類別的時候,如果演算邏輯相當複雜或者有改變的需求,可以將其抽出,依需求的情境分別以最基本的簡單工廠包裝生產邏輯,進階的將生產的方法以衍生類別包裝實作,以工廠方法時做,或者更進階地將相同主題類別加以包裝,並以蘊含工廠方法的方式多型地完成生產的工作。
以前第一次看到 Python 的 Decorator 時滿滿的黑人問號,後來有機會接觸裝飾者模式才豁然開朗,但也沒有深究,甚至沒有真的用過 Decorator。但最近重溫才發現其實裝飾者模式和 Python 的 Decorator 並不是完全的等號。Python 的 Decorator 更像是一種語法糖,利用 Python 函式 first class 的特性,能夠有更方便包裝函式的語法,可以為函式前後加入邏輯並且重利用程式碼。而要利用 Python 的 Decorator 也可以實踐 Decorator Pattern ,只是兩者並不是相等的,一個是語法模式,但背後有 Pattern 的精神;另一個則是 Pattern。
設計模式不會讓直觀上開發速度變得更快,反而在開發時會需要夠多的時間進行思考,然後才動手。但它的效益應該是當要維護、要擴充時,才能夠體現的,因為有良好的設計模式,程式碼的架構是充滿彈性且易於回應需求的,相較快速完成的架構可能缺少擴充的彈性,在面對需求時只能砍掉重練,或者是提心吊膽的修改程式碼害怕牽一髮動全身。無疑地如果在有需求變動的情境,使用設計模式先苦後甘是最好的選擇。