最新文章
什麼是物件導向?三大特性是什麼? (C#)
## 什麼是物件導向？ **物件導向是一種程式設計的方法，重點是把資料與行為包裝成物件。** ```C# // 類別 public class Animal { public string Name { get; set; } public int Age { get; set; } public string Sound { get; set; } public void Bark() { Console.WriteLine(Sound); } } // 物件 var cat = new Animal { Name = "kitty", Age = 1, Sound = "meow" }; cat.Bark(); // 輸出：meow ``` *** ## 三大特性？ ### 封裝(Encapsulation) > 把資料和邏輯包起來，只開放必要的方法，**避免外部直接修改**。 ```C# class BankAccount { private decimal balance; // 餘額 public BankAccount(decimal initialBalance) { balance = initialBalance; } public decimal Balance => balance; // 只允許查看餘額 // 存 public void Deposit(decimal amount) { if(amount <= 0) throw new ArgumentException("金額必須大於 0"); balance += amount; } // 提 public void Withdraw(decimal amount) { if(amount <= 0) throw new ArgumentException("金額必須大於 0"); if(amount > balance) throw new InvalidOperationException("餘額不足"); balance -= amount; } } // 使用範例 var account = new BankAccount(1000); account.Deposit(200); // 存入 200 account.Withdraw(500); // 提取 500 Console.WriteLine(account.Balance); // print: 700 ``` <br /> ### 繼承(Inheritance) > 子類別可以共用父類別的屬性和方法，**減少重複程式碼**。 ```C# public class Cat : Animal { public double Weight { get; set; } } // 使用範例 var kitty = new Cat { Name = "kitty", Age = 1, Sound = "meow", Weight = 4.2 }; kitty.Bark(); // print: meow ``` <br /> ### 多型(Polymorphism) > 相同方法名稱可以在不同類別中表現不同行為。\ > 使用關鍵字: `virtual`(可被覆寫)、`override`(覆寫父類別行為)。 ```C# public class Animal { public virtual void MakeSound() { Console.WriteLine("make some noise"); } } public class Cat : Animal { public override void MakeSound() { Console.WriteLine("meow meow"); } } // 使用範例 Animal cat = new Cat(); cat.MakeSound(); // print: meow meow ``` *** ## 最後的想法 物件導向最大的目的是**讓程式更容易維護、擴充與理解**。\ 透過封裝、繼承與多型，可以更有結構地設計程式，讓邏輯更清晰、可重用性更高。 不過，在實務開發中也要拿捏平衡。\ 若過度拆分類別、為了「物件導向」而「過度設計」，\ 反而會讓系統變得複雜、難以維護。
Git Commit Message 演進筆記：Conventional Commits
## 為什麼要使用 Conventional Commits? * **方便追蹤修改原因**：當需要找回過去改動的原因時，比起隨意的 commit message 更容易查找。 * **快速理解 log**：只要看 log 就能知道這次改了什麼，不用再打開整個程式碼去猜。 * **提升維護效率**：讓團隊合作或自己後續維護專案時更清楚、有效率。 *** ## Commit Message 範例 ### 格式 ```Markdown <type>(<scope>): <description> <body> issue: #<issue number> ``` <br /> ### 常用的 type 說明與範例 #### feat > 新功能、新介面、新流程 ```markdown feat(auth): 新增使用者登入功能 新增使用者登入 API，支援 email 與密碼驗證。 登入成功後會回傳 JWT Token，供後續 API 認證使用。 ``` #### fix > 修 bug、邏輯錯誤、漏寫條件 ```markdown fix(post): 修正貼文新增功能時，未正確帶入使用者 ID 修正資料庫插入時，因變數命名錯誤導致 user_id 為空值的問題。 已新增對 user_id 的驗證，避免類似錯誤。 ``` #### refactor > 改寫程式、但功能不變 ```Markdown refactor(order): 重構訂單計算邏輯 將訂單價格計算邏輯拆成獨立模組，提升可維護性。 修正部分邏輯錯誤，優化程式可讀性。 ``` #### style > 空格、命名、排版 ```Markdown style(ui): 調整按鈕樣式排版 ``` #### docs > README、註解、說明文件 ```Markdown docs(readme): 更新專案設定文件 新增 API 使用範例，補充專案啟動步驟與環境變數設定。 ``` #### chore > 升版本、搬套件、加工具 ```Markdown chore(build): 更新依賴套件版本 升級 Node.js 至 v20，更新主要依賴套件版本。 修正部分相容性問題。 ``` #### perf > 效能提升、跑更快 ```Markdown perf(order): 優化訂單查詢速度 改用索引優化資料庫查詢，降低查詢時間。 提升 API 回應效率。 issue: #55 ``` 另外還有 `ci`、`build`、`test` 等 type，適合有 CI/CD 或測試流程的專案使用。 > 📌 小提醒： > > 用 Conventional Commits 寫 message，最好保持一致，這樣回頭看 log 或生成 changelog 會更有效率。 *** ## 最後的想法 初次進入職場的時候，我常看到舊專案的程式碼裡有很多註解，但問題是註解很少隨著程式碼更新。 結果就是，註解和實際的程式碼常常對不起來，反而會造成更多誤解。 這讓我開始思考：「如果註解不可靠，那我要怎麼更清楚記錄程式的變化呢？」 後來接觸到 Conventional Commits，才發現原來 commit message 也可以成為專案的紀錄方式。 對我來說，這是一個新的習慣： * 註解不再是唯一的說明來源 * commit message 本身就能幫助追蹤歷史、理解修改原因 雖然我還在練習怎麼把 message 寫得更精準，但已經開始感受到它對維護專案的幫助。