SOLID到底是硬在哪裡
為什麼往往聽到這個解釋不清楚就直接畫個大叉叉，。

SOLID 是面向物件設計和程式設計中的五個基本原則簡稱合併的
不過在進入SOLID之前，筆者要稍微提一下，
SOLID，是物件導向程式設計基本原則沒錯，也非常重要，
但不要把它當成務必要遵守的要點。

這邊就來依序介紹SOLID，
S: Single responsibility principle(SRP)：單一職責原則(SRP)
"There should never be more than one reason for a class to change"
直翻:一個類別的改變不應該有多個原因

一個類別應只有一個原因去改變，關於這個要特別注意的一點，是單一職責而非單一一件事情。
舉個明確的例子給各位看看。

在這邊帶入筆者所寫得程式，
從最初Controller進入。

public class GetCarInfomationController : ControllerBase
{
    [HttpPost]
    public IActionResult Post(GetCarInfomationRequestModel model)
    {
        var returnData = model.GetCarInfomation();
        return Ok(new { message = "Car information received successfully." });
    }
}

可以看到，
在一開始的設計中GetCarInfomationRequestModel 這個Model，
有處理兩件事情，
一個是去接收傳入的值，
另一個是串建了取值的function，
這時候類別就有兩種可能產生改變，

接收HTTP POST請求處理 與 獲取車輛信息的相關邏輯，
這部分是可能有處理兩件職責，
那這個就有可能是違反SRP的狀況。

同時再重複說一次，
單一職責不代表是只做一件事情，
就像我這邊的單一職責是取得汽車詳細資訊，
而不是呼叫供應商取的資訊，
而且該單一職責的改動不會影響到不屬於該職責的其他程式。

假如有新寫一個Model，
而該職責是取得車子資料，
那麼如果獲取了車子執照或車子顏色，
都是屬於統一的職責，
不會違反SRP

GetCarDataModel model = new GetCarDataModel();
var getCarLicense = model.GetCarLicense();
var getCarColor = model.getCarColor();

那麼要處理一項業務，
必須要有很多職責才能處理要怎麼辦？
筆者在這邊舉個例子：

假設汽車訂單成立假設需要兩件事情
一是汽車詳細資訊
二是付款信息

那麼這兩項職責，
筆者更改其中任一項都不會影響到另一項，
所以這一個事情底下就會有兩個單一職責所組成，
而其中任一個職責有所更正都不會互相影響，
那麼這就不會是違反SRP。

所以單一職責不代表只能做一件事情，並且一項業務當中可能是透過多種單一職責組合而成的。

除此之外單一職責原則的核心思想是將不同的職責分開，
也就是不承擔多個不同的職責，
該理念在各個地方都可以進行，
就像筆者常常會使用到屬性上，

就以這個屬性來說，

public string Gasoline { get; set; }，

單位是String，
再設計的時候，
就有可能被設定很多職責，
例如:
"97汽油100KL"
"最高可負擔50KL汽油"
"100"

可以看到，這個屬性可能會被分配，
單位、型號、最高油量等等的職責。

這時候筆者就會希望這個屬性，
可以負責這個業務，
但不要一個屬性分擔多個職責，

以筆者所述，
會組成如下的Model

public class GasolineModel
{
	public string 型號 { get; set; }
	public string 最高油量 { get; set; }
	public string 單位 { get; set; }
}

---- 歷史
Robert C. Martin in his 2000 paper
http://staff.cs.utu.fi/~jounsmed/doos_06/material/DesignPrinciplesAndPatterns.pdf
SOLID在早期被論文中提及，可以看到SRP最初沒像其他功能被明確提及，後由Michael Feathers整理，
是不是有更早期的筆者不太確定，各位有興趣再繼續追吧！