精益求精！在 Spring Boot 應用中應用 SOLID 原則

作者：編程疏影 2024-09-30 11:51:07

開發前端

在本文中，我們首先討論了在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原則時的錯誤，隨后檢查了相關示例，以查看這些問題是如何修復的。

責任編輯：武曉燕來源：路條編程