精益求精！在 Spring Boot 應用中應用 SOLID 原則
作者：編程疏影
在本文中，我們首先討論了在Java應用中應用SOLID原則時的錯誤，隨后檢查了相關示例，以查看這些問題是如何修復的。
在軟件開發中，面向對象設計對于創建可輕易修改、擴展和重復使用的代碼至關重要。
SOLID原則是一組在面向對象編程和軟件開發中的五個設計原則，旨在創建更易維護、靈活和可擴展的軟件。這些原則由Robert C. Martin提出，廣泛作為設計清晰高效代碼的指導方針。“SOLID”一詞中的每個字母代表一個原則：
- 單一責任原則（SRP）
- 開放/封閉原則（OCP）
- 里氏替換原則（LSP）
- 接口隔離原則（ISP）
- 依賴反轉原則（DIP）
在本文中，我們將深入探討這些原則在Spring Boot應用中的使用。
單一責任原則（SRP）
Robert C. Martin描述道：
一個類應該有且僅有一個理由去改變。
單一責任原則有兩個關鍵點，如其名所示。
讓我們看看下面的錯誤用法示例。
@RestController
@RequestMapping("/report")
public class ReportController {
private final ReportService reportService;
public ReportController(ReportService reportService) {
this.reportService = reportService;
}
@PostMapping("/send")
public ResponseEntity<Report> generateAndSendReport(@RequestParam String reportContent,
@RequestParam String to,
@RequestParam String subject) {
String report = reportService.generateReport(reportContent);
reportService.sendReportByEmail(report, to, subject);
return new ResponseEntity<>(HttpStatus.OK);
}
}
// 錯誤實現
@Service
@Slf4j
public class ReportServiceImpl implements ReportService {
private final ReportRepository reportRepository;
public ReportServiceImpl(ReportRepository reportRepository) {
this.reportRepository = reportRepository;
}
@Override
public String generateReport(String reportContent) {
Report report = new Report();
report.setReportContent(reportContent);
return reportRepository.save(report).toString(); // 返回報告的字符串表示
}
@Override
public void sendReportByEmail(Long reportId, String to, String subject) {
Report report = findReportById(reportId);
sendEmail(report.getReportContent(), to, subject);
}
private Report findReportById(Long reportId) {
return reportRepository.findById(reportId)
.orElseThrow(() -> new RuntimeException("未找到報告")); // 修改為中文錯誤信息
}
private void sendEmail(String content, String to, String subject) {
log.info(content, to, subject);
}
}如您所見，ReportService有多個責任，違反了單一責任原則：
- 生成報告：負責在generateReport方法中生成報告并將其保存到倉庫。
- 通過電子郵件發送報告：在sendReportByEmail方法中也負責發送報告。
創建代碼時，需要避免在一個地方放入過多任務——無論是類還是方法。
這使代碼復雜且難以處理，也使得進行小修改變得棘手，因為它們可能影響代碼的其他部分，導致即使是小更新也需要測試所有內容。
讓我們糾正這個實現；
為遵循SRP，這些責任被分離到不同的類中。
@RestController
@RequestMapping("/report")
public class ReportController {
private final ReportService reportService;
private final EmailService emailService;
public ReportController(ReportService reportService, EmailService emailService) {
this.reportService = reportService;
this.emailService = emailService;
}
@PostMapping("/send")
public ResponseEntity<Report> generateAndSendReport(@RequestParam String reportContent,
@RequestParam String to,
@RequestParam String subject) {
Long reportId = Long.valueOf(reportService.generateReport(reportContent));
emailService.sendReportByEmail(reportId, to, subject);
return new ResponseEntity<>(HttpStatus.OK);
}
}
@Service
public class ReportServiceImpl implements ReportService {
private final ReportRepository reportRepository;
public ReportServiceImpl(ReportRepository reportRepository) {
this.reportRepository = reportRepository;
}
@Override
public String generateReport(String reportContent) {
Report report = new Report();
report.setReportContent(reportContent);
return reportRepository.save(report).toString(); // 返回報告的字符串表示
}
}
@Service
public class EmailServiceImpl implements EmailService {
private final ReportRepository reportRepository;
public EmailServiceImpl(ReportRepository reportRepository) {
this.reportRepository = reportRepository;
}
@Override
public void sendReportByEmail(Long reportId, String to, String subject) {
Report report = findReportById(reportId);
if (ObjectUtils.isEmpty(report) || !StringUtils.hasLength(report.getReportContent())) {
throw new RuntimeException("報告或報告內容為空"); // 修改為中文錯誤信息
}
}
private Report findReportById(Long reportId) {
return reportRepository.findById(reportId)
.orElseThrow(() -> new RuntimeException("未找到報告")); // 修改為中文錯誤信息
}
}重構后的代碼包括以下更改：
- ReportServiceImpl負責生成報告。
- EmailServiceImpl負責通過電子郵件發送報告——這些報告由ReportServiceImpl生成。
- ReportController管理生成和發送報告的過程，使用適當的服務。
開放/封閉原則（OCP）
開放-封閉原則表示一個類應該對擴展開放，對修改封閉。這有助于避免在工作應用中引入錯誤。簡單來說，這意味著您應該能夠向類中添加新功能，而無需更改現有代碼。
讓我們看看下面的錯誤用法示例。
public class ReportGeneratorService {
public String generateReport(Report report) {
if ("PDF".equals(report.getReportType())) {
return "生成PDF報告"; // 修改為中文輸出
} else if ("Excel".equals(report.getReportType())) {
return "生成Excel報告"; // 修改為中文輸出
} else {
return "不支持的報告類型"; // 修改為中文輸出
}
}
}在這個錯誤實現中，ReportService的generateReport方法包含條件語句來檢查報告類型，并直接生成相應的報告。這違反了開放-封閉原則，因為如果您想添加對新報告類型的支持，您需要修改這個類。
讓我們糾正這個實現；
public interface ReportGenerator {
String generateReport(Report report);
}
// 生成PDF報告的具體實現
@Component
public class PdfReportGenerator implements ReportGenerator {
@Override
public String generateReport(Report report) {
return String.format("為%s生成PDF報告", report.getReportType()); // 修改為中文輸出
}
}
// 生成Excel報告的具體實現
@Component
public class ExcelReportGenerator implements ReportGenerator {
@Override
public String generateReport(Report report) {
return String.format("為%s生成Excel報告", report.getReportType()); // 修改為中文輸出
}
}
// 遵循OCP的服務
@Service
public class ReportGeneratorService {
private final Map<String, ReportGenerator> reportGenerators;
@Autowired
public ReportGeneratorService(List<ReportGenerator> generators) {
this.reportGenerators = generators.stream()
.collect(Collectors.toMap(generator -> generator.getClass().getSimpleName(), Function.identity()));
}
public String generateReport(Report report, String reportType) {
return reportGenerators.getOrDefault(reportType, unsupportedReportGenerator())
.generateReport(report);
}
private ReportGenerator unsupportedReportGenerator() {
return report -> "不支持的報告類型"; // 修改為中文輸出
}
}- 引入了ReportGenerator接口，定義了一個通用的方法來生成報告。
- 創建了實現該接口的PdfReportGenerator和ExcelReportGenerator類。
- 引入了ReportGeneratorService，管理不同的報告生成實現，允許在不改變現有代碼的情況下添加新的報告生成器。
里氏替換原則（LSP）
里氏替換原則表示，如果您有一個類，您應該能夠用一個子類替換它，而不會對程序造成任何問題。換句話說，您可以在任何使用通用版本的地方使用特定版本，且一切仍然應正常工作。
讓我們看看下面的錯誤用法示例。
public class Bird {
public void fly() {
// 我會飛
}
public void swim() {
// 我會游泳
}
}
public class Penguin extends Bird {
@Override
public void fly() {
throw new UnsupportedOperationException("企鵝不能飛"); // 修改為中文錯誤信息
}
}讓我們糾正這個實現；
public class Bird {
// 方法
}
public interface Flyable {
void fly(); // 飛
}
public interface Swimmable {
void swim(); // 游泳
}
public class Penguin extends Bird implements Swimmable {
@Override
public void swim() {
System.out.println("我會游泳");
}
}
public class Eagle extends Bird implements Flyable {
@Override
public void fly() {
System.out.println("我會飛");
}
}Bird類作為鳥類的基類，包含所有鳥類共享的通用屬性或方法。引入Flyable和Swimmable接口以表示特定行為。在Penguin類中，實現Swimmable接口以反映企鵝的游泳能力；在Eagle類中，實現Flyable接口以反映老鷹的飛行能力。通過將特定行為分離到接口中，并在子類中實現它們，我們遵循了里氏替換原則，允許我們在不引起意外問題的情況下切換子類。
接口隔離原則（ISP）
接口隔離原則指出，較大的接口應拆分為較小的接口。這樣可以確保實現類只需關心對它們感興趣的方法。
讓我們看看下面的錯誤用法示例。
public interface Athlete {
void compete(); // 比賽
void swim(); // 游泳
void highJump(); // 跳高
void longJump(); // 跳遠
}
// 錯誤實現違反接口隔離
public class JohnDoe implements Athlete {
@Override
public void compete() {
System.out.println("路條小哥開始比賽");
}
@Override
public void swim() {
System.out.println("路條小哥開始游泳");
}
@Override
public void highJump() {
// 路條小哥來說不必要
}
@Override
public void longJump() {
// 路條小哥來說不必要
}
}假設John Doe是一名游泳運動員，他被迫提供高跳和長跳的空實現，這對他作為游泳運動員的角色無關緊要。
讓我們糾正這個實現；
public interface Athlete {
void compete(); // 比賽
}
public interface JumpingAthlete {
void highJump(); // 跳高
void longJump(); // 跳遠
}
public interface SwimmingAthlete {
void swim(); // 游泳
}
// 正確的接口隔離實現
public class JohnDoe implements Athlete, SwimmingAthlete {
@Override
public void compete() {
System.out.println("路條小哥開始比賽");
}
@Override
public void swim() {
System.out.println("路條小哥開始游泳");
}
}原始的Athlete接口被拆分為三個獨立接口：Athlete用于一般活動，JumpingAthlete用于跳躍相關活動，SwimmingAthlete用于游泳。這遵循了接口隔離原則，確保一個類不被迫實現它不需要的方法。
依賴反轉原則（DIP）
依賴反轉原則（DIP）指出，高層模塊不應依賴于低層模塊；兩者都應依賴于抽象。抽象不應依賴于細節。
讓我們看看下面的錯誤用法示例。
@Service
public class PayPalPaymentService {
public void processPayment(Order order) {
// 支付處理邏輯
}
}
@RestController
public class PaymentController {
private final PayPalPaymentService paymentService;
public PaymentController() {
this.paymentService = new PayPalPaymentService();
}
@PostMapping("/pay")
public void pay(@RequestBody Order order) {
paymentService.processPayment(order);
}
}讓我們糾正這個實現；
public interface PaymentService {
void processPayment(Order order); // 處理支付
}
@Service
public class PayPalPaymentService implements PaymentService {
@Override
public void processPayment(Order order) {
// 支付處理邏輯
}
}
@RestController
public class PaymentController {
private final PaymentService paymentService;
public PaymentController(PaymentService paymentService) {
this.paymentService = paymentService;
}
@PostMapping("/pay")
public void pay(@RequestBody Order order) {
paymentService.processPayment(order);
}
}- 引入了PaymentService接口。
- 在控制器的構造函數中注入PaymentService接口，以提供控制器中的抽象。控制器依賴于抽象（PaymentService），允許注入任何實現該接口的類。
結論
SOLID原則在面向對象編程（OOP）中至關重要，因為它們提供了一組設計更易維護、靈活和可擴展的軟件的指南和最佳實踐。在本文中，我們首先討論了在Java應用中應用SOLID原則時的錯誤，隨后檢查了相關示例，以查看這些問題是如何修復的。
責任編輯：武曉燕
來源：
路條編程
