你是否经历过这样的时刻：打开一个刚入职同事留下的项目，满怀期待地想kankan“大神”的架构，结果发现为了读取一个简单的配置项，代码里竟然层层叠叠地套了五六个类？那一刻，你的内心大概是崩溃的，甚至想把手里的咖啡泼到显示器上。这种为了所谓的“灵活性”和“ 性”，把简单问题复杂化的行为，就是我们常说的过度设计。

在Java开发领域，这种风气尤为盛行。我们似乎总在担心：“万一以后要换数据库怎么办？”“万一配置源要改成从Redis读取怎么办？”于是我们在项目还没上线时就先搭好了一套足以支撑淘宝双十一的抽象架构。结果呢？需求从未变过这些精心设计的接口和抽象类，成了维护者眼中的“屎山”，无人敢动，无人Neng懂。

今天我们就来聊聊如何在这个充满诱惑的技术世界里保持清醒，拒绝过度设计，写出真正“人话”般的代码。

hen多刚接触架构设计的同学，总喜欢从“配置管理”入手练手。毕竟这kan起来是整个系统的基石，必须得“高大上”一点。于是你可Neng会kan到下面这种令人窒息的代码结构。

为了读取一个键值对，我们定义了接口、抽象类、具体实现，甚至还搞了个单例管理器。这就像是为了喝一口水，先建了一个自来水厂。

// 定义一个获取配置数据的顶层契约
public interface ConfigurationSource {
    String fetchValue;
}
// 抽象的加载逻辑基类
public abstract class BaseConfigLoader implements ConfigurationSource {
    protected Map internalStorage = new HashMap<>;
    public abstract void performLoading;
}
// 针对Properties文件的具体实现
public class FileBasedConfigLoader extends BaseConfigLoader {
    @Override
    public void performLoading {
        // 这里省略读取文件的IO逻辑
    }
    @Override
    public String fetchValue {
        return internalStorage.get;
    }
}
// 全局统一的配置访问入口
public class GlobalConfigContext {
    private static GlobalConfigContext uniqueInstance;
    private ConfigurationSource source;
    private GlobalConfigContext {}
    public static GlobalConfigContext getInstance {
        if  {
            synchronized  {
                if  {
                    uniqueInstance = new GlobalConfigContext;
                }
            }
        }
        return uniqueInstance;
    }
    public void setSource {
        this.source = source;
    }
    public String getProperty {
        return source.fetchValue;
    }
}

kan着这一堆代码，我只想问一句：我们到底是在写业务逻辑，还是在给面试官展示设计模式？Ru果只是为了读取一个 `.properties` 文件，Java 自带的 `java.util.Properties` 早就够用了或者geng现代一点，直接用 Spring Boot 的自动配置。

在现代化的开发环境下尤其是使用 Spring Boot 时绝大多数基础设施问题框架douYi经帮我们解决了。别再自己手写单例和工厂了那是在浪费公司的钱。

// 直接使用注解绑定配置
@Component
@ConfigurationProperties
public class AppSettings {
    private String projectName;
    private int connectionTimeout;
    // 省略 getters 和 setters，Lombok 也Ke以搞定
}
// 在需要的地方直接注入
@Autowired
private AppSettings settings;
String currentName = settings.getProjectName;

核心原则： 永远记住Ru果框架Yi经提供了成熟、稳定的解决方案，千万不要试图自己去“重新发明轮子”，除非你的轮子Neng飞。

设计模式是双刃剑。用得好是利器，用不好就是自残。hen多同学在学完《设计模式》这本书后kan哪里dou觉得需要抽象，哪里dou需要策略。比如仅仅是为了打印一条日志，有人竟然Neng整出一套“策略+工厂+管理器”的组合拳。

请kan下面的代码，为了实现“以后可Neng要改成文件日志或数据库日志”的幻想，我们预先付出了巨大的代码量。

// 定义日志策略接口
public interface LoggingStrategy {
    void executeLog;
}
// 控制台输出策略
public class ConsoleOutputStrategy implements LoggingStrategy {
    @Override
    public void executeLog {
        System.out.println;
    }
}
// 策略工厂
public class LoggerFactory {
    public static LoggingStrategy getStrategy {
        if ) {
            return new ConsoleOutputStrategy;
        }
        throw new IllegalArgumentException;
    }
}
// 日志上下文管理器
public class LoggingContext {
    private final LoggingStrategy currentStrategy;
    public LoggingContext {
        this.currentStrategy = strategy;
    }
    public void log {
        currentStrategy.executeLog;
    }
}
// 业务调用方
public class Demo {
    public static void main {
        LoggingContext logger = new LoggingContext);
        logger.log;
    }
}

这还没完，Ru果以后要加个文件日志，你还得新建类，改工厂。为了打印这一行字，你写了5个类，跳转了4个文件。Ru果我是你的同事，我大概会在Code Review时直接在群里发一个“？”。

在项目初期，或者需求极其明确时直接使用Zui简单的方式。等到真的需要复杂日志时直接引入 Log4j2 或 Slf4j，别自己写。

// Zui朴素的写法
public class SimpleLogger {
    public static void info {
        System.out.println;
    }
}
// 调用
SimpleLogger.info;

核心原则： 当系统中只有一种实现方式，或者未来三年内dou不可Neng改变时接口、工厂、策略模式统统dou是累赘。等到真正需要 的那一天再重构也不迟，那时候你才有真实的业务场景作为依据，而不是在瞎猜。

Spring Boot 的兴起让 Web 开发变得极其简单，但hen多团队依然沿袭着旧时代的 EJB 思维，层层接口，层层抽象。Zui典型的症状就是：为了查一个用户，必须经过 Repository 接口、Service 接口、ServiceImpl 实现类、DTO 转换器，Zui后才Neng拿到数据。

kankan下面这个“根据ID查用户”的功Neng，这简直是样板代码的教科书。

// 泛型仓储接口
public interface BaseRepository {
    Optional queryById;
    List queryAll;
    T saveData;
    void removeData;
}
// 业务服务接口
public interface UserService {
    UserDTO getUserDetails;
}
// 服务实现类
public class UserServiceImpl implements UserService {
    private final BaseRepository userRepo;
    private final UserDtoTransformer transformer;
    public UserServiceImpl(BaseRepository userRepo, 
                           UserDtoTransformer transformer) {
        this.userRepo = userRepo;
        this.transformer = transformer;
    }
    @Override
    public UserDTO getUserDetails {
        return userRepo.queryById
            .map
            .orElseThrow -> new UserNotFoundException);
    }
}
// 专门的转换器类
public class UserDtoTransformer {
    public UserDTO convertToDTO {
        return new UserDTO, entity.getFullName);
    }
}

仅仅是查个用户，就动用了 1 个实体类、1 个 Repository 接口、1 个 Service 接口、1 个 Service 实现类、1 个 DTO 类、1 个转换器类。Ru果每个功Nengdou这么写，代码行数蹭蹭往上涨，但实际逻辑却少得可怜。这种代码kan起来hen“规范”，实际上是在浪费生命。

在 Spring Data JPA 的加持下hen多简单的 CRUD 操作根本不需要写 Service 接口，甚至不需要写实现类。至于 DTO，Ru果内部服务和外部 API 返回的字段完全一致，直接返回 Entity 又何妨？别拿“领域驱动设计”来吓唬人，大部分 CRUD 系统根本不需要那么纯粹的领域模型。

@Service
public class UserService {
    @Autowired
    private UserRepository userRepository; // Spring Data JPA 自动生成实现
    public User getUserById {
        return userRepository.findById
            .orElseThrow -> new RuntimeException);
    }
}

核心原则： DTO只有在跨层传输或者字段差异巨大时才需要引入。否则，直接返回实体类，让代码清爽一点。

过度设计的本质，往往源于程序员的一种“焦虑感”——我们害怕未来的变化，害怕现在的代码无法应对未知的挑战。于是我们通过堆砌抽象层来获得一种虚假的安全感。

但现实是残酷的：你预测的未来90%dou不会发生。 当那个“未来”真的来临时你之前设计的抽象往往也不适用，还得推倒重来。

真正的架构大师，不是kan谁写出了多少个接口，而是kan谁Neng用Zui少的代码、Zui清晰的结构解决问题。YAGNI原则应该刻在每个人的键盘上：你不会需要它。

下次在写 `public interface` 之前，请先停下来喝口茶，问自己一个问题：“我现在真的需要它吗？还是只是为了显得我hen专业？”

Ru果是后者，请删掉它，直接写具体的实现。你的同事，以及三个月后的你自己，dou会感谢你的克制。