接口与具体实现命名规范探讨：哪种方案更优？含数据源场景

两种主流方案的优劣势掰扯清楚 #

方案1：接口用核心名，实现类加Impl后缀（比如UserRepository + UserRepositoryImpl） #

• 好处：接口名干净利落，直接点明核心业务职责，不用额外过滤无意义标识，一眼就能get到它的作用。
• 坏处：项目规模扩大后，大量Impl后缀会显得重复冗余；如果后续需要多个实现（比如不同数据库的用户仓库），Impl无法区分具体实现，得改成UserRepositoryMySQLImpl这类长命名，越变越啰嗦。

方案2：接口加I前缀，实现类用核心名（比如IUserRepository + UserRepository） #

• 好处：能快速区分接口和实现类，IDE中按I前缀搜索接口更高效；如果只有一个默认实现，实现类名称清爽简洁。
• 坏处：I前缀只是单纯的类型标识，没有传递任何业务或技术信息，平白增加名称长度；不少开发者认为这是老派匈牙利命名法的遗留，不符合现代面向对象“命名聚焦职责而非类型”的理念。

更实用的替代方案：按场景/技术给实现类起名 #

如果项目中可能存在多个实现类，真心推荐接口用核心职责命名，实现类直接用具体场景或技术特性区分，彻底抛弃Impl或I这类无意义标识：

• 示例1：接口UserRepository，实现类可以是JdbcUserRepository（JDBC方式实现）、RedisUserRepository（Redis缓存实现）
• 示例2：接口PaymentProcessor，实现类AlipayPaymentProcessor、WechatPayPaymentProcessor

这种方案的优势很明显：

• 实现类名称直接体现技术或业务特性，可读性拉满
• 没有冗余的通用标识，命名精准不啰嗦
• 新增实现类时扩展自然，无需修改原有命名逻辑

针对LocalDataSource/RemoteDataSource场景的具体建议 #

对于这类明确区分数据源类型的场景，这么搞最舒服：

1. 先定义基础接口，比如UserDataSource，明确核心数据操作职责
2. 实现类直接用场景标识命名：LocalUserDataSource、RemoteUserDataSource

• 要是上下文已经明确业务范围（比如在用户模块内，大家默认指代用户数据源），也可以把接口简化为DataSource，实现类叫LocalDataSource、RemoteDataSource

这样既避免了Impl或I的冗余，又能清晰区分不同实现的定位，完全符合高内聚的命名原则。

内容的提问来源于stack exchange，提问作者Etienne Lawlor