當 AI 已經能快速生成語法正確的程式碼,工程師的價值還剩下什麼?答案或許是「判斷力」,知道什麼時候該用、什麼時候不該用某個設計模式
本系列將以「柴咖啡」的成長故事貫穿 30 天:從得簡單點餐系統,到串接外送平台,再到連鎖店規模的訂單與庫存管理。透過這間店的擴張歷程,逐一實作 SOLID 原則與常見的設計模式中,並在每個階段思考:如果沒把這個階段學到的判斷條件講清楚就把系統丟給 AI 設計,它會在哪裡設計過頭、又會漏掉什麼
這是從新手視角出發、誠實記錄理解過程的學習筆記,希望能陪你我一起,練出在 AI 時代仍然不可取代的架構判斷力
昨天用 Bridge 把「報表種類」跟「匯出格式」兩個維度拆開,結構型系列也來到最後一篇 今天來聊 Flyweight 享元模式 原文的定義,來自 Design...
結構型 Pattern 我們到 Day21 的 Flyweight 告一段落 接下來我們繼續進入行為型 Pattern(Behavioral)(灑花) 柴咖啡的...
昨天用 Strategy 把促銷算法跟結帳流程拆開,今天我們繼續介紹行為型 Pattern 柴咖啡的故事,也陸續走到連鎖店規模化的階段,庫存跟訂單的一舉一動,開...
昨天用 Observer 讓庫存跟訂單的狀態變化,可以同步通知多個對象,今天我們繼續行為型 Pattern 柴咖啡的故事,也持續在連鎖店規模化的路上,客訴退款這...
昨天用 Command 把客訴處理的動作包成一張張可以撤銷、重做的指令,今天我們繼續行為型 Pattern 柴咖啡連鎖化之後,分店越開越多、新店員也越來越多,但...
昨天用 Template Method 把飲料製作的 SOP 鎖進父類別,今天延續行為型 Pattern State 狀態模式 原文的定義,來自 Design...
昨天用 State 把訂單的狀態機拆成物件,讓「現在能不能做這件事」交給狀態自己決定 今天要處理的是另一種常見的情境:一個請求進來,不知道最後會是誰處理,只知道...
昨天用 Chain of Responsibility 把客訴依照店員、店長、客服中心的權限逐層上交 今天要處理的,是柴咖啡訂單背後另一種常見的情境:好幾個角色...
昨天用 Mediator 把廚房、收銀、外送平台之間的協調邏輯收進一個中介者 今天聊聊柴咖啡最後一個 Pattern:Iterator 迭代器模式 原文的定義,...