
我們對 Null Object 的使用合理嗎?
最近工作上以及私下跟朋友討論時,剛好都遇到了 Null
(不存在)類型的處理,通常我不會特別去在意這件事情,然而近年讀了一些關於 Null
的文章後(如:The worst mistake of computer science)對於這件事情的看法有不少改觀。
對我來說軟體開發是一件非常有趣的事情,然而許多時候並不一定能滿足條件。
為此,我開始思考如何讓大眾「開心寫程式,製作有趣事物」的方法。
最近工作上以及私下跟朋友討論時,剛好都遇到了 Null
(不存在)類型的處理,通常我不會特別去在意這件事情,然而近年讀了一些關於 Null
的文章後(如:The worst mistake of computer science)對於這件事情的看法有不少改觀。
端午節連假利用空檔轉換心情時,把去年重寫後沒有完成的玩具再次拿出來挑戰,剛好在處理一對多的關聯時發現 Domain-Driven Design(領域驅動設計) 中對於 Aggregate(聚合)要作為統一操作其關聯的 Entity(實體)的原因。
有段時間沒有寫 Domain-Driven Design(以下簡稱 DDD)的主題,最近剛好跟一些朋友討論以及做了不少實驗,覺得可以針對這些題目再一次討論在 Ruby on Rails 中導入會遇到的問題。
在遊戲開發中寫測試一直以來都是被認為相當困難的一件事情,雖然有很多人嘗試,但我們仍沒有找到一個很好的方法解決。
同時,寫測試對許多人來說是一種拖慢開發速度的工作,這次我在每年都會參加 Global Game Jam 中挑戰用 48 小時的時間開發,運用這段時間學到的 Domain-Driven Design(領域驅動設計)、Clean Architecture(清楚架構)、敏捷開發、ATDD(驗收測試驅動開發)等技巧來做實驗。
最近在實作一個會員集點功能的時候意外發現很適合作為「領域事件(Domain Event)」的例子,在很多情況下其實不容易去描述這個概念,然而這個例子倒是很好的反應這個概念,以及 Rails 的特性所產生的變化。
之前在查資料時,在 Twitter 上看到 DHH 對 DCI (Data Context Interaction) 的看法同時上週的我對 Domain-Driven Design 的理解(2022 年)這篇文章也提到了 DDD 跟 DCI 不互斥,而且能夠改善某些設計上的問題。
因為把 Domain-Driven Design: The First 15 years 看完後腦中有了非常多想法,為了不要太快把這些東西忘記,只能盡快寫成文章記錄下來。
簡單來說,我認為 Domain-Driven Design 是一種「觀念」而不是理論或者實踐,他更接近於將「模型(Model)」的概念帶入到程式設計中,也因此在書中提到 Domain-Driven Design 是沒有嚴格規定,只有接近跟遠離核心的差異。