在專案中多人開發時，我們通常會制訂 Lint 或是 coding style 但一般不會去制定一定要用 FP 或是 OOP 去開發，為了保持架構的整潔，再來要介紹 OOP 的 SOLID 原則。
更詳細可以去看 Clean Code 無暇的程式碼的 chapter 10

SOLID

• Single-responsibility principle(SRP) : 單一職責原則

• Open–closed principle(OCP) : 開放封閉原則

• Liskov substitution principle(LSP) : 里氏替換原則

• Interface segregation principle(ISP) : 介面隔離原則

• Dependency inversion principle(DIP) : 依賴反向原則

SOLID原則不僅僅是將每一個 function 都寫好，他更像是將所有每個寫好的 function 用有邏輯且清晰的架構將程式碼組合起來。

SRP 單一功能原則

一個功能只做一件事，減少功能的複雜度，避免修改功能時互相影響。

A class should only have a single responsibility, that is, only changes to one part of the software’s specification should be able to affect the specification of the class.

這個其實不只在 OOP ，FP也是適用這個原則的，對我來說這個原則不用像書上說得這麼複雜，只要能保持自己的 function 或是功能物件一次只負責一件事就可以了，如果可以保證只負責一件事，那就不會產生 side effects，這部分在 Day4 的時候有介紹。

OCP 開放封閉原則

可以任意擴充功能在實體上，但不修改原本功能。主要有兩個特點 :

1. 修改具有封閉性

修改 A 的程式碼，B 也要跟著一起修改，改完以後，結果 C 又發生錯誤，這就代表修改並沒有封閉性，代表他們有高度相依也就是高耦合性，大家都不希望出現這個情況吧。

封閉性就是為了不要讓這個情況發生的，也就是要降低耦合，避免這個狀況發生

2. 擴充具有開放性

假設程式碼之間高度相依，我們很難專注於擴充新的程式碼，會因為「高耦合性」不斷思考會不會發生「改了 A，B 也要跟著一起改」的情況。我們應該在儘可能不改動原始的程式碼的條件下，擴充新的功能。

通常在這部分，我會以FP的方式實作，擴充新功能時透過 SRP 寫一個專屬於此功能的 function 以免出現高耦合性的情況

參考 - 使人瘋狂的-solid-原則