單一責任原則 C.
我們先來解決這個問題。看看下面的程式碼:
public class BankAccount
{
public BankAccount() {}
public string AccountNumber { get; set; }
public decimal AccountBalance { get; set; }
public decimal CalculateInterest()
{
// Code to calculate Interest
}
}
這裡, BankAccount 類包含帳戶的屬性,還計算帳戶的利息。現在看看我們從業務收到的一些變更請求:
- 請新增新的 Property AccountHolderName 。
- 引入了一些新規則來計算利息。
這是完全不同型別的變更請求。一個是改變功能; 其他人正在影響功能。我們有兩種不同型別的理由來改變一個類。這違反了單一責任原則。
現在讓我們嘗試實施 SRP 來解決這種違規行為。看下面的程式碼:
public interface IBankAccount
{
string AccountNumber { get; set; }
decimal AccountBalance { get; set; }
}
public interface IInterstCalculator
{
decimal CalculateInterest();
}
public class BankAccount : IBankAccount
{
public string AccountNumber { get; set; }
public decimal AccountBalance { get; set; }
}
public class InterstCalculator : IInterstCalculator
{
public decimal CalculateInterest(IBankAccount account)
{
// Write your logic here
return 1000;
}
}
現在我們的 BankAccount 類只負責銀行賬戶的屬性。如果我們想為計算利息新增任何新的業務規則,我們不需要更改 BankAccount 類。 ** ****
而且,如果需要新增新的 Property AccountHolderName , InterestCalculator 類也不需要更改。所以這是單一責任原則的實施。 ** **
我們還使用 Interfaces 在 InterestCalculator 和 BankAccount 類之間進行通訊。這將有助於我們管理類之間的依賴關係。