面试题：Java设计模式里开闭原则与SOLID其他原则的关联及应用

综合运用原则设计电商系统代码结构

开闭原则（OCP）：
- 在电商系统中，例如订单处理模块。假设最初只有普通订单处理逻辑，随着业务发展，可能需要处理促销订单、团购订单等特殊订单。我们可以定义一个订单处理接口 OrderProcessor，普通订单实现类 NormalOrderProcessor 实现该接口。当有新的订单类型时，通过创建新的实现类（如 PromotionOrderProcessor）来扩展功能，而不是修改已有的 NormalOrderProcessor 代码。
- 代码示例：

// 订单处理接口
interface OrderProcessor {
    void processOrder(Order order);
}

// 普通订单处理实现类
class NormalOrderProcessor implements OrderProcessor {
    @Override
    public void processOrder(Order order) {
        // 普通订单处理逻辑
        System.out.println("Processing normal order: " + order.getOrderId());
    }
}

// 促销订单处理实现类
class PromotionOrderProcessor implements OrderProcessor {
    @Override
    public void processOrder(Order order) {
        // 促销订单处理逻辑
        System.out.println("Processing promotion order: " + order.getOrderId());
    }
}

里氏替换原则（LSP）：
- 对于上述订单处理，所有的订单处理实现类（如 NormalOrderProcessor 和 PromotionOrderProcessor）都必须满足 OrderProcessor 接口的契约。这意味着在使用 OrderProcessor 的地方，任何具体的实现类都可以被安全替换，而不会影响系统的正确性。
- 例如，有一个订单处理服务类 OrderProcessingService，它依赖于 OrderProcessor：

class OrderProcessingService {
    private OrderProcessor orderProcessor;

    public OrderProcessingService(OrderProcessor orderProcessor) {
        this.orderProcessor = orderProcessor;
    }

    public void process(Order order) {
        orderProcessor.processOrder(order);
    }
}

这里无论是传入 NormalOrderProcessor 还是 PromotionOrderProcessor 的实例，OrderProcessingService 都能正确工作，符合里氏替换原则。

依赖倒置原则（DIP）：
- 在电商系统的用户模块，假设用户服务依赖于用户数据访问层。按照依赖倒置原则，用户服务不应该依赖于具体的数据访问实现类，而是依赖于抽象接口。
- 定义用户数据访问接口 UserDao 和具体实现类 UserDaoImpl：

// 用户数据访问接口
interface UserDao {
    User getUserById(int userId);
}

// 用户数据访问实现类
class UserDaoImpl implements UserDao {
    @Override
    public User getUserById(int userId) {
        // 从数据库获取用户数据逻辑
        return new User(userId, "John Doe");
    }
}

用户服务 UserService 依赖于 UserDao 接口：

class UserService {
    private UserDao userDao;

    public UserService(UserDao userDao) {
        this.userDao = userDao;
    }

    public User getUserById(int userId) {
        return userDao.getUserById(userId);
    }
}

这样，如果需要更换数据访问方式（如从数据库改为缓存），只需要创建新的实现 UserDao 接口的类，而不需要修改 UserService 的代码。

可能遇到的冲突及解决方案

冲突：在遵循开闭原则进行扩展时，可能会发现新的扩展与里氏替换原则冲突。例如，新的订单处理实现类 SpecialOrderProcessor 虽然实现了 OrderProcessor 接口，但它的处理逻辑与原有的订单处理逻辑有很大差异，导致在一些依赖 OrderProcessor 的通用逻辑中无法正确工作。
解决方案：仔细设计接口的契约，确保所有实现类都能满足接口的基本行为要求。对于特殊的逻辑，可以通过接口方法的参数或者额外的配置来处理，而不是破坏里氏替换原则。例如，可以在 OrderProcessor 的 processOrder 方法中传入一个包含特殊配置信息的参数，让不同的实现类根据这个参数来处理特殊逻辑，同时保持基本的处理流程一致。
冲突：依赖倒置原则可能与开闭原则在实际应用中产生冲突。当依赖的抽象接口需要修改以适应新的功能需求时，可能会影响到所有依赖该接口的类，这违背了开闭原则。
解决方案：在设计抽象接口时，要充分考虑到未来可能的扩展点，尽量使接口具有足够的通用性和灵活性。如果必须修改接口，可以采用版本控制的方式，同时提供兼容旧版本的过渡方案，以减少对现有依赖类的影响。例如，在接口中添加新方法时，为旧的实现类提供默认实现，使其仍然能够在不修改太多代码的情况下继续工作。

星途面试题库

面试题：Java设计模式里开闭原则与SOLID其他原则的关联及应用

知识考点

面试题答案

综合运用原则设计电商系统代码结构

可能遇到的冲突及解决方案