多同方法单例类的代码复用、测试方案及单元测试必要性咨询

1. 存在更优方案减少代码重复，同时保留独立实例与各自锁 #

你可以通过基础公共接口+抽象基类的方式消除重复代码，同时满足每个类独立单例、自有锁的需求：

优化后代码示例 #

// 定义公共基础接口，统一声明通用方法
public interface ICommonOperations
{
    void CommonMethod1();
    void CommonMethod2();
}

// 各业务接口继承基础接口，无需重复定义通用方法
public interface IClassA : ICommonOperations { }
public interface IClassB : ICommonOperations { }

// 抽象基类封装通用逻辑与实例级锁
public abstract class CommonBase : ICommonOperations
{
    // 每个实例独立持有锁，避免跨实例锁竞争
    protected readonly object _lockObj = new object();

    public void CommonMethod1()
    {
        lock (_lockObj)
        {
            // 通用业务逻辑实现
        }
    }

    public void CommonMethod2()
    {
        lock (_lockObj)
        {
            // 通用业务逻辑实现
        }
    }

    // 若子类有差异化逻辑，可定义抽象方法留待实现
    // public abstract void SpecificBusinessMethod();
}

// 业务类继承抽象基类并实现对应接口
public class ClassA : CommonBase, IClassA
{
    // ClassA特有逻辑或重写方法
}

public class ClassB : CommonBase, IClassB
{
    // ClassB特有逻辑或重写方法
}

// 依旧保持独立单例注册，每个接口对应唯一实例
services.AddSingleton<IClassA, ClassA>();
services.AddSingleton<IClassB, ClassB>();

这个方案的核心优势：

• 消除了接口与通用方法的重复定义
• 每个单例实例持有独立的锁（_lockObj为实例成员，非静态），完全满足临界区保护需求
• 保留了原有独立接口、独立单例的设计，不依赖共享实例导致的耦合

2. 优化方案的自动化测试策略 #

针对这个优化方案，测试可以分层进行：

（1）抽象基类的通用逻辑测试 #

• 功能正确性测试：单独实例化抽象基类的测试子类（或用模拟工具），验证CommonMethod1、CommonMethod2的核心逻辑是否符合预期
• 线程安全测试：用多线程并发调用通用方法，验证锁的有效性——比如设置共享计数器，并发调用后检查结果是否正确，无线程安全问题

（2）业务子类的特有逻辑测试 #

• 针对每个业务类（如ClassA、ClassB），单独测试其特有方法或重写逻辑
• 依赖注入对应接口（如IClassA）进行测试，确保单例实例的行为符合预期；若测试需要隔离，可在每个测试方法中创建独立的服务容器实例，避免单例状态污染测试

（3）单例独立性验证 #

• 测试从容器中多次获取IClassA是否为同一实例，IClassA与IClassB是否为不同实例
• 验证两个实例的临界区操作互不干扰（比如同时调用两个实例的通用方法，检查各自的状态是否独立）

3. 若无更优方案时的单元测试建议 #

即使保持原有重复接口与类的设计，仍然需要为每个类编写单元测试，但可以优化效率：

• 如果多个类的通用方法实现完全一致，可使用参数化测试（如xUnit的[Theory]），将不同类作为参数传入，复用测试逻辑
• 若每个类的通用方法有差异化实现，则必须单独编写测试覆盖各自逻辑
• 重点测试每个类的锁机制是否生效，以及单例实例的独立性——确保不同类的临界区操作不会互相影响

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