代碼壞味道 (Code Smells) 完整識別與重構指南：軟體品質改善最佳實踐

Thu, 17 Mar 2022 22:50:11 +0800

代碼壞味道 (Code Smells) 完整識別與重構指南

概述

代碼壞味道是指代碼中存在的設計缺陷和結構問題，雖然不會導致程序功能錯誤，但會影響代碼的可讀性、可維護性和可擴展性。本文將深入探討各種代碼壞味道的識別方法、重構技巧和預防策略。

經典四大軟體設計問題

1. Rigidity (僵化性) - 難以變更

問題描述： 系統中存在過多的相依性，導致任何小的變更都需要修改大量相關代碼。

症狀：

修改一個小功能需要改動多個模組
開發人員害怕進行代碼變更
估算工作量困難，因為變更範圍難以預測

壞味道示例：

// 僵化的訂單處理系統
public class OrderService {
    private DatabaseConnection dbConnection;
    private EmailService emailService;
    private InventoryService inventoryService;
    private PaymentService paymentService;
    private LoggingService loggingService;
    
    public void processOrder(Order order) {
        // 直接依賴具體實現，難以變更
        dbConnection.connect("jdbc:mysql://localhost:3306/orders");
        
        // 硬編碼的業務邏輯
        if (order.getType().equals("PREMIUM")) {
            order.setDiscount(0.1);
        } else if (order.getType().equals("STANDARD")) {
            order.setDiscount(0.05);
        }
        
        // 緊密耦合的操作順序
        inventoryService.reserveItems(order.getItems());
        paymentService.processPayment(order.getPayment());
        dbConnection.saveOrder(order);
        emailService.sendConfirmationEmail(order.getCustomer());
        loggingService.log("Order processed: " + order.getId());
    }
}

重構解決方案：

SOLID 設計原則完整指南：物件導向程式設計的五大核心原則

Thu, 08 Jul 2021 21:20:39 +0800

概述

SOLID 是物件導向程式設計和軟體架構設計中五個核心設計原則的縮寫，由 Robert C. Martin（Uncle Bob）在 21 世紀初期提出。這些原則旨在讓軟體設計更加容易理解、靈活且可維護。

SOLID 原則不僅適用於物件導向程式設計，也是現代軟體架構的基石，從微服務設計到 Clean Architecture 都深受其影響。

SOLID 原則概覽

首字母	英文原則名稱	中文名稱	核心概念
S	Single Responsibility Principle	單一職責原則	一個類別應該只有一個改變的理由
O	Open/Closed Principle	開閉原則	對擴展開放，對修改封閉
L	Liskov Substitution Principle	里氏替換原則	子類別應該能完全替換父類別
I	Interface Segregation Principle	介面隔離原則	客戶端不應該依賴它不需要的介面
D	Dependency Inversion Principle	依賴反轉原則	依賴於抽象而非具體實作

1. Single Responsibility Principle (SRP) - 單一職責原則

定義

一個類別應該只有一個引起它變化的原因

核心概念

高內聚性：類別內部的方法和屬性應該為同一個目標服務
低耦合性：減少類別之間的依賴關係
明確責任：每個類別都應該有明確且單一的職責

違反 SRP 的範例

// ❌ 違反 SRP：一個類別承擔多種職責
public class User {
    private String name;
    private String email;
    
    // 用戶資料驗證職責
    public boolean validateEmail(String email) {
        return email.contains("@") && email.contains(".");
    }
    
    // 用戶持久化職責
    public void saveToDatabase() {
        // 資料庫存儲邏輯
        System.out.println("儲存用戶到資料庫");
    }
    
    // 用戶通知職責
    public void sendWelcomeEmail() {
        // 郵件發送邏輯
        System.out.println("發送歡迎郵件");
    }
    
    // 用戶報表職責
    public String generateUserReport() {
        return "用戶報表: " + name + " - " + email;
    }
}

遵循 SRP 的重構範例

// ✅ 遵循 SRP：職責分離
// 1. 用戶實體類別（僅負責用戶資料）
public class User {
    private String name;
    private String email;
    
    public User(String name, String email) {
        this.name = name;
        this.email = email;
    }
    
    // Getter and Setter methods
    public String getName() { return name; }
    public String getEmail() { return email; }
    public void setName(String name) { this.name = name; }
    public void setEmail(String email) { this.email = email; }
}

// 2. 用戶驗證服務（僅負責驗證邏輯）
@Service
public class UserValidator {
    
    public boolean validateEmail(String email) {
        return email != null && 
               email.contains("@") && 
               email.contains(".") &&
               email.length() > 5;
    }
    
    public boolean validateName(String name) {
        return name != null && 
               name.trim().length() > 0 && 
               name.length() <= 50;
    }
    
    public ValidationResult validateUser(User user) {
        ValidationResult result = new ValidationResult();
        
        if (!validateName(user.getName())) {
            result.addError("用戶名格式無效");
        }
        
        if (!validateEmail(user.getEmail())) {
            result.addError("郵箱格式無效");
        }
        
        return result;
    }
}

// 3. 用戶持久化服務（僅負責資料存取）
@Repository
public class UserRepository {
    
    public void save(User user) {
        // 資料庫存儲邏輯
        System.out.println("儲存用戶到資料庫: " + user.getName());
    }
    
    public User findByEmail(String email) {
        // 查詢邏輯
        return new User("找到的用戶", email);
    }
    
    public List<User> findAll() {
        // 查詢所有用戶
        return Arrays.asList(new User("用戶1", "user1@example.com"));
    }
}

// 4. 用戶通知服務（僅負責通知邏輯）
@Service
public class UserNotificationService {
    
    public void sendWelcomeEmail(User user) {
        System.out.println("發送歡迎郵件給: " + user.getEmail());
    }
    
    public void sendPasswordResetEmail(User user) {
        System.out.println("發送密碼重設郵件給: " + user.getEmail());
    }
    
    public void sendAccountActivationEmail(User user) {
        System.out.println("發送帳戶啟用郵件給: " + user.getEmail());
    }
}

// 5. 用戶報表服務（僅負責報表生成）
@Service
public class UserReportService {
    
    public String generateUserReport(User user) {
        return String.format("用戶報表\n姓名: %s\n郵箱: %s\n生成時間: %s", 
                           user.getName(), 
                           user.getEmail(), 
                           LocalDateTime.now());
    }
    
    public String generateUsersListReport(List<User> users) {
        StringBuilder report = new StringBuilder("用戶列表報表\n");
        users.forEach(user -> 
            report.append(String.format("- %s (%s)\n", user.getName(), user.getEmail()))
        );
        return report.toString();
    }
}

// 6. 用戶服務協調器（組合各種服務）
@Service
public class UserService {
    
    private final UserValidator userValidator;
    private final UserRepository userRepository;
    private final UserNotificationService notificationService;
    
    public UserService(UserValidator userValidator, 
                      UserRepository userRepository,
                      UserNotificationService notificationService) {
        this.userValidator = userValidator;
        this.userRepository = userRepository;
        this.notificationService = notificationService;
    }
    
    public Result<User> createUser(String name, String email) {
        User user = new User(name, email);
        
        // 驗證用戶資料
        ValidationResult validation = userValidator.validateUser(user);
        if (!validation.isValid()) {
            return Result.failure("驗證失敗: " + validation.getErrors());
        }
        
        // 儲存用戶
        userRepository.save(user);
        
        // 發送歡迎郵件
        notificationService.sendWelcomeEmail(user);
        
        return Result.success(user);
    }
}

SRP 的好處

降低複雜度：每個類別的責任明確，易於理解
提高可讀性：程式碼結構清晰，功能劃分明確
增強可維護性：修改某個功能時，只需要關注特定的類別
提升可測試性：職責單一的類別更容易進行單元測試
促進重用性：功能獨立的類別可以在不同場景中重複使用

2. Open/Closed Principle (OCP) - 開閉原則

定義

軟體實體（類別、模組、函數等）應該對擴展開放，對修改封閉

Clean Code on Bill.Lin's Notes