面向对象如何添加新功能方法

IT行业相对于一般传统行业，发展更新速度更快，一旦停止了学习，很快就会被行业所淘汰。所以我们需要踏踏实实的不断学习，精进自己的技术，尤其是初学者。今天golang学习网给大家整理了《面向对象设计中如何合理添加新功能方法》，聊聊，我们一起来看看吧！

本文探讨了在面向对象设计中，当需要添加一个将类型A实例转换为类型B实例的功能`foo`时，如何选择其放置位置。核心在于根据“职责”原则，结合SOLID和GRASP等设计准则，判断该功能是作为A的方法、B的静态方法（或工厂方法），还是独立的服务或用例类的方法。通过具体示例，文章指导读者如何在不同业务场景下做出最佳设计决策，以提升代码的内聚性、可维护性和可扩展性。

在面向对象编程（OOP）中，设计一个新功能时，如何确定其最佳归属是一个常见且关键的问题。假设我们需要实现一个功能foo，它接收一个类型A的实例，并产生一个类型B的实例（A和B均为接口或类）。常见的两种设计方案是：将foo作为A的一个实例方法，或作为B的一个静态方法。从纯技术实现角度看，这两种方式可能都能达到目的，但从OOP的设计原则出发，其背后的“职责”分配却大相径庭。

核心原则：职责驱动设计

在OOP中，一个类或方法应该承担明确的职责。当我们面临上述选择时，应参照SOLID原则（单一职责原则、开放封闭原则、里氏替换原则、接口隔离原则、依赖反转原则）和GRASP模式（通用职责分配软件模式），来判断哪种设计更能体现职责的合理分配，从而提高代码的内聚性、可维护性和可扩展性。

下面通过几个具体的业务场景来阐述如何根据职责进行设计选择：

场景一：领域模型中的行为（方法属于源对象）

当foo代表的是类型A自身的一个核心行为或操作，并且这个操作的结果是类型B，那么将foo作为A的一个实例方法是自然的选择。这符合单一职责原则，即A负责管理和执行与自身状态相关的行为。

示例：订单的下单操作

假设A是Order（订单），B是ProcessingResult（处理结果），foo是Place（下单）。一个订单应该能够执行“下单”这个动作，并返回下单的处理结果。

public class Order {
    private String orderId;
    private OrderStatus status;
    // ... 其他订单属性

    public ProcessingResult place() {
        // 执行下单逻辑，如状态变更、库存扣减、生成处理结果等
        if (this.status == OrderStatus.NEW) {
            this.status = OrderStatus.PLACED;
            System.out.println("订单 " + orderId + " 已成功下单。");
            return new ProcessingResult(true, "订单下单成功。");
        } else {
            System.out.println("订单 " + orderId + " 状态不正确，无法下单。");
            return new ProcessingResult(false, "订单状态不正确。");
        }
    }
}

public class ProcessingResult {
    private boolean success;
    private String message;

    public ProcessingResult(boolean success, String message) {
        this.success = success;
        this.message = message;
    }

    // ... getter方法
}

在这种情况下，Order类明确地承担了“下单”的职责，其方法直接操作或反映了订单对象的状态变化。

场景二：对象的创建（静态工厂方法或独立工厂）

当foo的主要职责是从某些参数（可能是类型A的实例）创建类型B的实例时，它更像一个工厂方法。此时，将其作为类型B的静态方法，或者一个独立的工厂类的方法，是更合适的选择。这符合创建者模式（Creator Pattern）或工厂方法模式。

示例：从参数创建B对象

假设A是Parameters（参数），B是某个领域类，foo是Create。B类可能需要从一组参数中初始化自身。

public class B {
    private String name;
    private int value;

    private B(String name, int value) { // 私有构造器，强制通过工厂方法创建
        this.name = name;
        this.value = value;
    }

    public static B create(Parameters parameters) {
        // 根据parameters的属性创建B的实例
        if (parameters.isValid()) {
            return new B(parameters.getName(), parameters.getValue());
        } else {
            throw new IllegalArgumentException("无效的创建参数。");
        }
    }
    // ... getter方法
}

public class Parameters {
    private String name;
    private int value;

    public Parameters(String name, int value) {
        this.name = name;
        this.value = value;
    }

    public boolean isValid() {
        return name != null && !name.isEmpty() && value > 0;
    }
    // ... getter方法
}

或者，如果创建逻辑复杂，或者需要创建不同类型的B，可以考虑引入一个独立的工厂类：

public class BFactory {
    public static B createFromParameters(Parameters parameters) {
        if (parameters.isValid()) {
            return new B(parameters.getName(), parameters.getValue());
        } else {
            throw new IllegalArgumentException("无效的创建参数。");
        }
    }
}

静态工厂方法的好处是封装了对象的创建逻辑，并且可以返回接口类型，隐藏具体实现。独立的工厂类则更符合单一职责原则，将创建逻辑与被创建类的核心业务逻辑分离。

场景三：用例或服务层操作（独立服务类）

当foo代表一个更高级别的业务操作、一个用例（Use Case）或一个服务，它可能需要协调多个领域对象来完成一个复杂的任务，而不仅仅是A或B自身的行为。在这种情况下，创建一个独立的用例类或服务类来封装这个操作是最佳实践。这符合单一职责原则（用例类只负责一个业务用例的执行），也常用于分层架构（如六边形架构）。

示例：执行一个Foo用例

假设A是FooUseCaseParameters（用例参数），B是FooUseCaseResult（用例结果），foo是Execute。这个Execute方法代表了一个完整的业务流程。

public class FooUseCase {
    // 依赖注入所需的领域服务或仓储
    private final SomeDomainService domainService;
    private final AnotherRepository anotherRepository;

    public FooUseCase(SomeDomainService domainService, AnotherRepository anotherRepository) {
        this.domainService = domainService;
        this.anotherRepository = anotherRepository;
    }

    public FooUseCaseResult execute(FooUseCaseParameters parameters) {
        // 1. 验证参数
        if (!parameters.isValid()) {
            return new FooUseCaseResult(false, "参数无效。");
        }

        // 2. 根据参数从仓储获取或创建领域对象
        DomainObjectA a = anotherRepository.findById(parameters.getAId());
        if (a == null) {
            return new FooUseCaseResult(false, "找不到相关对象A。");
        }

        // 3. 执行核心业务逻辑，可能调用领域服务或A的方法
        boolean success = domainService.performAction(a, parameters.getData());

        // 4. 根据结果构建FooUseCaseResult
        if (success) {
            return new FooUseCaseResult(true, "用例执行成功。", a.getCurrentState());
        } else {
            return new FooUseCaseResult(false, "用例执行失败。", a.getCurrentState());
        }
    }
}

public class FooUseCaseParameters {
    private String aId;
    private String data;
    // ... 构造器、getter、isValid方法
}

public class FooUseCaseResult {
    private boolean success;
    private String message;
    private String finalStateOfA;
    // ... 构造器、getter
}

这种设计将复杂的业务流程封装在一个独立的类中，使得业务逻辑清晰、可测试，并且与领域对象的细节解耦。

总结与注意事项

• 没有银弹： 面对设计选择，没有一个放之四海而皆准的答案。最佳设计总是取决于具体的业务上下文、领域模型以及团队对设计原则的理解。
• 职责是核心： 始终思考“谁应该负责完成这项工作？”。如果功能是对象自身的核心行为，就放在对象内部；如果功能是创建对象，就放在工厂或目标对象本身；如果功能是协调多个对象完成一个业务流程，就放在一个独立的用例或服务类中。
• SOLID/GRASP是指南： 经常回顾SOLID原则和GRASP模式，它们提供了评估设计优劣的框架。例如，单一职责原则（SRP）是决定方法放置位置的关键考量。
• 可维护性和可测试性： 好的设计能够提高代码的可维护性和可测试性。职责清晰的类更容易理解和修改，也更容易编写单元测试。
• 演进与重构： 设计不是一蹴而就的。随着项目的发展和对业务理解的加深，可能会发现原有的设计不再是最优解。此时，应勇于进行重构，将功能移动到更合适的位置。

通过深入理解职责驱动的设计理念，并结合具体的业务场景和设计原则，开发者可以做出更合理、更健壮的面向对象设计决策。

终于介绍完啦！小伙伴们，这篇关于《面向对象如何添加新功能方法》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！