文章列表

2020-07-07

重溫《深入淺出設計模式》反覆器模式 (Book Review of Head First Design Pattern, Iterator Pattern)

反覆器已經被實踐在許多當代的語言之中,作為集合類型的低階類別所使用。以往並沒有特別感受到 Iterator 的美好,只覺得高階的語法 (python) 方便好用,而有時候得到物件回傳 Iterator 反而不知所措 (例如 Beautiful Soup)。但重溫反覆器模式後,才曉得作為底層的反覆器有多重要,同時理解它也有助於自行實踐整合不同型別的集合類別進行迭代。

2020-07-04

如何開發 Windows Service 使用 .Net 及 Topshelf

從來沒有想過自行開發 Windows Service,一直以來都是在伺服器上直接執行 batch 或者經由工作排程器的方式執行想要達成的服務,但偶然契機下學習到 Windows Service 可以得到更多的便利性,同時藉由安裝 Topshelf 僅需要以 Console 開發上做延伸即可,非常實用。

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-07-01

使用 Visual Studio 開發,你不能錯過的 Quick Action 及 Code Snippet

不同於以往覺得 Intellisense 就是一切的想法,Quick Action 以及 Code Snippet 重新塑造自己對於 Visual Studio 編輯程式碼過程的方法,原本一直覺得要花錢買 ReSharper 才能得到那種行雲流水的開發體驗,但 Visual Studio 2019 原生所支援的 Quick Action 就已經非常好用,本篇筆記用以紀錄如何以 Quick Action 以及 Code Snippet 來進行開發。

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)

設計模式不會讓直觀上開發速度變得更快,反而在開發時會需要夠多的時間進行思考,然後才動手。但它的效益應該是當要維護、要擴充時,才能夠體現的,因為有良好的設計模式,程式碼的架構是充滿彈性且易於回應需求的,相較快速完成的架構可能缺少擴充的彈性,在面對需求時只能砍掉重練,或者是提心吊膽的修改程式碼害怕牽一髮動全身。無疑地如果在有需求變動的情境,使用設計模式先苦後甘是最好的選擇。