> For the complete documentation index, see [llms.txt](https://code.national-cat.me/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://code.national-cat.me/clean-code/class.md).

# 類別

比較大的函式

我會把 Class 分成兩種

1. 函式庫（library）
2. 元件（component）

### 函式庫

像是 Laravel 的 Controller，可以任意建立 public methods。

### 元件

Laravel 大部分的功能都是元件，像是 Command、ServiceProvider、Middleware，會要你實作或覆寫某些方法。~~當然，你也可以把這種元件當函式庫來擴充，結果程式碼就會很髒。~~

這些元件都是根據 [SOLID](https://w.wiki/7tBC) 物件導向設計原則來設計的。

直接解釋 SOLID  除了很難懂外，還又臭又長，所以從結果講重點：

1. 藉由抽象類別（abstract class）或介面（interface）限制可被使用的功能，這樣可以把所有實作功能抽象成同一件事。
2. 元件是從抽象開始被理解和設計，所以元件必須實作（implement）於抽象類別或介面。
3. 如果不在抽象類別和介面的規範內，必須封裝（defind to private）。
4. 元件本身必須是單數，單數比較好理解和使用

***

### 函式庫 vs 元件

函式庫剛開始寫起來很快很方便，但久了會很難維護，甚至裡面的方法可能沒有任何關聯性。元件剛開始要花時間規劃，但對於之後使用的人來說會很友善，因為能用的功能都寫在抽象層裡。

通常函式庫或函式過於複雜的時候，就會重新設計成幾個物件來簡化流程。像是，購物車的贈品條件計算就很適合單獨寫成一個元件，這個元件大概會有這些功能：

```markdown
1. 累計贈品條件：滿額贈、滿件數贈
2. 判斷購物車贈品是否達到條件
3. 回傳條件差距
```

若沒使用元件，就可能是幾個變數在好幾個地方遊走，除了分散開發者的注意力外，也很難寫測試和擴充，這也是大多系統隱藏的技術債。