如何在不违反OOP原则下拆分ObjectManager的子功能？

是否应该拆分功能？ #

必须拆分。你提到的三个子功能分属完全不同的职责领域：

• 数据库加载/保存属于数据持久化职责
• 对象打印属于输出/视图职责
• 对象的增删改属于数据业务管理职责

遵循单一职责原则，拆分后每个类的职责边界清晰，代码更易维护、测试和复用——比如DatabaseManager可以被其他需要持久化能力的类复用，调整ObjectPrinter的输出格式时也不会影响核心的数据管理逻辑。

实现方式选择 #

你的判断完全正确：

• 选项a（继承）不可取：ObjectManager和DatabaseManager/ObjectPrinter是“has-a”（拥有）关系，而非“is-a”（是一种）关系，继承会强制让ObjectManager变成打印机或数据库管理器，违背逻辑和里氏替换原则。
• 选项b（组合/依赖）是正确方向，但你的示例代码可以优化：
  1. 不要硬编码实例化依赖：通过构造函数注入DatabaseManager和ObjectPrinter，而非直接在类内部new，这样能轻松替换为Mock对象做测试，也符合依赖倒置原则。
  2. 封装内部成员：把dbManager和objPrinter设为private，只暴露上层需要的方法，避免外部直接操作内部依赖。

优化后的代码示例：

public abstract class ObjectManager<T> {
    private final DatabaseManager<T> dbManager;
    private final ObjectPrinter<T> objPrinter;

    // 构造函数注入依赖
    protected ObjectManager(DatabaseManager<T> dbManager, ObjectPrinter<T> objPrinter) {
        this.dbManager = dbManager;
        this.objPrinter = objPrinter;
    }

    public List<T> loadObjects(String filename) throws IOException, ClassNotFoundException {
        List<T> database = dbManager.readSerializedObject(filename);
        return database != null ? database : new ArrayList<>();
    }

    public void saveObjects(String filename, List<T> database) throws IOException {
        dbManager.writeSerializedObject(filename, database);
    }

    public void printObjects(List<T> database) {
        objPrinter.printObjects(database);
    }

    public void printObject(T object) {
        objPrinter.printObject(object);
    }

    // 定义对象增删改的抽象方法，由子类实现具体逻辑
    public abstract void addObject(List<T> database, T object);
    public abstract void updateObject(List<T> database, T object);
    public abstract void deleteObject(List<T> database, T object);
}

补充建议 #

• 如果ObjectManager的核心是对象的增删改操作，它更像一个业务协调类——只负责调度持久化和输出功能，不自己实现底层细节。
• 若不同类型的T需要差异化的增删改逻辑，保留抽象类是合理的；如果所有T的管理逻辑一致，可改为具体类。
• 对象的增删改操作建议将List<T>作为参数传入，或封装为类内部状态，根据业务场景选择即可。

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