一、单一职责原则(SRP)
* 定义:一个类应该只有一个引起它变化的原因。
* 解释:意味着一个类应该专注于做一件事情,当需求发生变化时,只影响到一个类。这有助于降低类间的耦合,使得代码更易于理解和维护。
示例场景:图书管理系统
假设我们正在设计一个图书管理系统的后端逻辑。在这个系统中,我们需要处理图书的添加、删除、查询等功能,同时也需要记录图书的借阅信息。
* 未按单一职责原则的示例:
在这个实现中,BookManager
类不仅负责图书的管理(添加、删除、查询),还负责图书借阅的记录。这意味着如果有需求变更,比如需要改进图书借阅的逻辑,那么这个类就需要改变,同时图书的基本管理功能也可能受到影响。
public class BookManager
{private List<Book> books;private Dictionary<int, BorrowRecord> borrowRecords;public BookManager(){books = new List<Book>();borrowRecords = new Dictionary<int, BorrowRecord>();}public void AddBook(Book book){books.Add(book);}public void RemoveBook(int bookId){books.RemoveAll(b => b.Id == bookId);borrowRecords.Remove(bookId);}public Book GetBookById(int bookId){return books.FirstOrDefault(b => b.Id == bookId);}public void BorrowBook(int bookId, int userId){var book = GetBookById(bookId);if (book != null && !borrowRecords.ContainsKey(bookId)){borrowRecords.Add(bookId, new BorrowRecord(bookId, userId));}}public void ReturnBook(int bookId){borrowRecords.Remove(bookId);}
}
* 按单一职责原则的示例:
将归还和借阅的方法分解出来,单独成一个类
public class BookRepository
{private List<Book> books;public BookRepository(){books = new List<Book>();}public void AddBook(Book book){books.Add(book);}public void RemoveBook(int bookId){books.RemoveAll(b => b.Id == bookId);}public Book GetBookById(int bookId){return books.FirstOrDefault(b => b.Id == bookId);}
}public class BorrowService
{private Dictionary<int, BorrowRecord> borrowRecords;public BorrowService(){borrowRecords = new Dictionary<int, BorrowRecord>();}public void BorrowBook(int bookId, int userId){if (!borrowRecords.ContainsKey(bookId)){borrowRecords.Add(bookId, new BorrowRecord(bookId, userId));}}public void ReturnBook(int bookId){borrowRecords.Remove(bookId);}
}
二、开放封闭原则(OCP)
* 定义:软件实体(类、模块、函数等)应该是可扩展的,但是不可修改的。
* 解释:当系统的需求发生变化时,我们应该能够通过增加新的代码来扩展原有的功能,而不是修改已有的代码。这有助于保持系统的稳定性,减少因为修改现有代码带来的风险。
示例场景:计算不同类型的订单折扣
假设我们正在开发一个电子商务平台,需要为不同类型的订单计算折扣。最初,我们的系统只支持两种类型的订单:标准订单和批量订单,其中批量订单可以享受额外的折扣。
* 未遵循开放封闭原则的示例:
public enum OrderType
{Standard,Bulk
}public class OrderDiscountCalculator
{public decimal CalculateDiscount(Order order){if (order.Type == OrderType.Standard){return order.Total * 0.95m; // 标准订单95%的折扣}else if (order.Type == OrderType.Bulk){return order.Total * 0.90m; // 批量订单90%的折扣}return order.Total;}
}
在这个实现中,OrderDiscountCalculator
类直接在 CalculateDiscount
方法中根据订单类型计算折扣。如果未来需要添加新的订单类型,比如会员订单,我们需要修改这个方法,这违反了OCP。
* 遵循开放闭合原则示例:
// 折扣策略接口
public interface IDiscountStrategy
{decimal CalculateDiscount(Order order);
}// 标准订单折扣策略
public class StandardOrderDiscount : IDiscountStrategy
{public decimal CalculateDiscount(Order order){return order.Total * 0.95m;}
}// 批量订单折扣策略
public class BulkOrderDiscount : IDiscountStrategy
{public decimal CalculateDiscount(Order order){return order.Total * 0.90m;}
}// 订单折扣计算器
public class OrderDiscountCalculator
{private readonly IDiscountStrategy _discountStrategy;public OrderDiscountCalculator(IDiscountStrategy discountStrategy){_discountStrategy = discountStrategy;}public decimal CalculateDiscount(Order order){return _discountStrategy.CalculateDiscount(order);}
}
为了遵循OCP,我们可以使用策略模式,将折扣的计算逻辑封装到独立的策略类中,然后在 OrderDiscountCalculator
中使用这些策略。
现在,如果我们需要添加新的订单类型(比如会员订单),我们只需要实现 IDiscountStrategy
接口并创建一个新的策略类,然后在应用中适当地使用它,而不需要修改现有的 OrderDiscountCalculator
类。这样,我们的系统就对扩展开放,对修改封闭了。
为了在应用中使用这些策略,你可以使用依赖注入框架,根据订单类型动态地注入正确的策略实例。这种方式提高了代码的灵活性和可扩展性,同时减少了修改现有代码的风险。
* 那么我们现在用依赖注入的方式实现 【遵循OCP的策略模式】
步骤1:定义接口和策略类
我们已经定义了
IDiscountStrategy
接口和具体的策略类(StandardOrderDiscount
和BulkOrderDiscount
),这里不再重复。步骤2:配置依赖注入容器
public void ConfigureServices(IServiceCollection services) {// 注册策略类services.AddTransient<IDiscountStrategy, StandardOrderDiscount>();services.AddTransient<IDiscountStrategy, BulkOrderDiscount>();// 可以继续注册更多策略类,如会员订单策略// 注册 OrderDiscountCalculator 类,它将依赖于策略类services.AddTransient<OrderDiscountCalculator>(); }
这里我们使用了
AddTransient
方法,这意味着每次请求一个新的服务实例时,都会创建一个新的实例。步骤3:选择正确的策略
为了让控制器能够根据订单类型选择正确的策略,我们需要在创建
OrderDiscountCalculator
实例时传入正确的策略。这可以通过创建工厂方法或使用条件逻辑来实现。例如,你可以创建一个DiscountStrategyFactory
类,它根据订单类型返回相应的策略实例。public class DiscountStrategyFactory {private readonly IServiceProvider _serviceProvider;public DiscountStrategyFactory(IServiceProvider serviceProvider){_serviceProvider = serviceProvider;}public IDiscountStrategy GetStrategy(Order order){switch (order.Type){case OrderType.Standard:return _serviceProvider.GetRequiredService<StandardOrderDiscount>();case OrderType.Bulk:return _serviceProvider.GetRequiredService<BulkOrderDiscount>();// 可以添加更多case处理其他类型的订单default:throw new ArgumentException("Invalid order type.");}} }
在控制器中根据订单类型选择正确的类
public class OrdersController : Controller {private readonly DiscountStrategyFactory _strategyFactory;private readonly OrderDiscountCalculator _discountCalculator;public OrdersController(IServiceProvider serviceProvider){_strategyFactory = new DiscountStrategyFactory(serviceProvider);_discountCalculator = new OrderDiscountCalculator(_strategyFactory.GetStrategy(GetOrderById(orderId)));}// ... }
-------------------------------- ^.^ 写累了,下次再写 ^.^---------------------------------
三、里氏替换原则(LSP)
* 定义:子类必须能够替换其基类。
* 解释:任何基类可以出现的地方,子类一定可以出现。这保证了在使用继承时,子类的行为与基类一致,不会破坏程序的正确性
四、接口隔离原则(ISP)
* 定义:不应该强迫客户程序依赖于它们不用的方法。
* 解释:一个类对另一个类的依赖应该建立在最小的接口上,即不应该为实现接口而实现接口,而是应该实现真正需要的方法。这有助于降低类间的耦合,使得接口更纯粹,更易于理解和使用。
五、依赖倒置原则(DIP)
* 定义:高层模块不应该依赖于低层模块,二者都应该依赖于抽象;抽象不应该依赖于细节,细节应该依赖于抽象。
* 解释:高层模块(如业务逻辑层)应依赖于抽象接口或基类,而不是具体的实现类。这有助于解耦系统中的各个部分,使得系统更灵活,更易于扩展和维护。