概述： SOLID 原則是一組五項設計原則，旨在使軟體設計更易於理解、靈活和易於維護。如果正確套用這些原則，可以產生幹凈而健壯的程式碼。在本文中，我們將深入探討每個 SOLID 原則，並提供 C# 中的實際範例。單一責任原則 （SRP）單一責任原則指出，一個類應該只有一個改變的理由。換句話說，一個類應該有一個單一的責任。合規範例：public class Order { public void CreateOrder(OrderDetails orderDetails) { // Create an order based on the provided deta
SOLID 原則是一組五項設計原則，旨在使軟體設計更易於理解、靈活和易於維護。如果正確套用這些原則，可以產生幹凈而健壯的程式碼。在本文中，我們將深入探討每個 SOLID 原則，並提供 C# 中的實際範例。
單一責任原則 （SRP）
單一責任原則指出，一個類應該只有一個改變的理由。換句話說，一個類應該有一個單一的責任。
推薦範例：
public classOrder
{
publicvoidCreateOrder(OrderDetails orderDetails)
{
// Create an order based on the provided details
}
}
public classOrderPrinter
{
publicvoidPrintOrder(Order order)
{
// Print the order
}
}
不推薦範例：
public classOrder
{
publicvoidCreateOrder(OrderDetails orderDetails)
{
// Create an order based on the provided details
// And print the order in this method
}
}
在合規範例中，該類負責建立訂單，該類負責打印訂單。但是，在沖突範例中，類有兩個職責，這使得維護變得更加困難。OrderOrderPrinterOrder
開/閉原理 （OCP）
開放/封閉原則指出，軟體實體（類、模組、函式等）應該開放以進行擴充套件，但對修改應該關閉。
推薦範例：
publicabstract classShape
{
publicabstractdoubleArea();
}
public classCircle : Shape
{
publicdouble Radius { get; set; }
publicoverridedoubleArea() => Math.PI \* Radius \* Radius;
}
public classRectangle : Shape
{
publicdouble Width { get; set; }
publicdouble Height { get; set; }
publicoverridedoubleArea() => Width \* Height;
}
不推薦範例：
public classAreaCalculator
{
publicdoubleCalculateArea(object shape)
{
if (shape isCircle circle)
{
return Math.PI * circle.Radius * circle.Radius;
}
elseif (shape isRectangle rectangle)
{
return rectangle.Width * rectangle.Height;
}
// Adding new shapes requires modifying this class
return0;
}
}
在合規範例中，階層是開放的，可以擴充套件，因為您可以透過建立新的子類別來輕松添加新形狀，而無需修改現有程式碼。相比之下，沖突範例要求每次添加新形狀時修改類。ShapeAreaCalculator
芮氏替代原則 （LSP）
Liskov 替換原則指出，超類的物件應該可以用子類別的物件替換，而不會影響程式的正確性。
推薦範例：
public classBird
{
publicvirtualvoidFly() { /* Common flying behavior */ }
}
public classSparrow : Bird
{
publicoverridevoidFly() { /* Sparrow-specific flying behavior */ }
}
public classOstrich : Bird
{
publicoverridevoidFly() { /* Ostrich-specific behavior (non-flying) */ }
}
不推薦範例：
public classBird
{
publicvoidFly() { /* Common flying behavior */ }
}
public classOstrich : Bird
{
publicnewvoidFly() { /* Ostrich-specific behavior (non-flying) */ }
}
在相容的範例中，and 類都擴充套件了類並根據需要重寫了方法。在違規範例中，我們必須使用關鍵字來隱藏基礎類別方法，這違反了 Liskov 替換原則。SparrowOstrichBirdFlynew
介面隔離原則 （ISP）
介面隔離原則指出，不應強制客戶端依賴它們不使用的介面。
推薦範例：
publicinterfaceIWorker
{
voidWork();
}
publicinterfaceIEater
{
voidEat();
}
public classWorker : IWorker
{
publicvoidWork() { /* Working behavior */ }
}
public classSuperWorker : IWorker, IEater
{
publicvoidWork() { /* Working behavior */ }
publicvoidEat() { /* Eating behavior */ }
}
不推薦範例：
publicinterfaceIWorker
{
voidWork();
voidEat();
}
public classWorker : IWorker
{
publicvoidWork() { /* Working behavior */ }
publicvoidEat() { /* Eating behavior (unnecessary for this class) */ }
}
在相容的範例中，該類同時實作 和 介面，而該類僅實作 .在沖突範例中，類被強制實作該方法，即使它不需要它。SuperWorkerIWorkerIEaterWorkerIWorkerWorkerEat
依賴關系反轉原理 （DIP）
依賴倒置原則指出，高級模組不應依賴於低階模組。兩者都應該依賴於抽象。
推薦範例：
publicinterfaceIMessageSender
{
voidSendMessage(string message);
}
public classEmailSender : IMessageSender
{
publicvoidSendMessage(string message)
{
// Send the message via email
}
}
public classNotificationService
{
privateIMessageSender _messageSender;
publicNotificationService(IMessageSender messageSender)
{
_messageSender = messageSender;
}
publicvoidSendNotification(string message)
{
_messageSender.SendMessage(message);
}
}
不推薦範例：
public classEmailSender
{
publicvoidSendEmail(string email, string message)
{
// Send an email
}
}
public classNotificationService
{
privateEmailSender _emailSender;
publicNotificationService(EmailSender emailSender)
{
_emailSender = emailSender;
}
publicvoidSendNotification(string email, string message)
{
_emailSender.SendEmail(email, message);
}
}
在相容範例中，取決於介面，這允許輕松替換不同的訊息發送實作。在沖突範例中，與類緊密耦合，因此更難更改訊息發送機制。
結論
理解和套用 SOLID 原則可以生成更易於維護和可延伸的程式碼。透過遵循這些原則，您可以建立更易於測試、重構和擴充套件的軟體，最終產生更強大、適應力更強的程式碼庫。
如果你喜歡我的文章，請給我一個贊！謝謝
