java - 这是策略模式的实现吗？

Question

我已经构建了一个软件架构，现在我想知道它是否可以被认为匹配一些已知的设计模式:

所有层都由包含小块逻辑的多个接口(interface)组成:

HasService 指示类包含某些 E 和 Q 类型的 EntityService 实现。

public interface HasService<E extends BaseEntity, Q extends QueryParams> {
    EntityService<E, Q> getService();
}

InsertDtoEndpoint表示一个类能够接收格式为D的json输入，将其映射到E，插入它，然后返回之前将其映射回 D。

public interface InsertDtoEndpoint<E extends AbstractBaseEntity, D extends Dto, Q extends QueryParams>
    extends Endpoint, HasService<E, Q> {

    @POST
    default Response insert(D dto) {
        return ok(executeInsert(dto));
    }

    default D executeInsert(D dto) {
        E mapped = mapInsertRequestRecordToPersistentEntity(dto);
        return mapInsertResponseRecordToDto(getService().save(mapped));
    }

    E mapInsertRequestRecordToPersistentEntity(D dto);
    D mapInsertResponseRecordToDto(E entity);

}

然后，通过http调用访问的实际端点由以下接口(interface)组成:

public class SomeEntityEndpoint implements InsertDtoEndpoint<SomeEntity, SomeDto, DefaultQueryParam>, FetchEndpoint<SomeEntity, DefaultQueryParams>, FindEndpoint<SomeEntity, DetailedDto, DefaultQueryParams> {

    SomeEntity mapInsertRequestRecordToPersistentEntity(SomeDto dto) { 
        //map to entity 
    }

    SomeDto mapInsertResponseRecordToDto(SomeEntity entity) {
        //map to dto
    }

    DetailedDto mapFindResponseRecordToDto(SomeEntity entity) {
        //Map to dto
    }

    getService() {
        //Return service..
    }

 }

Answer 1

首先，需要指出的是，模式有不同级别。我不是在谈论类型(如创建型、结构型、行为型……)，而是对代码库的实际影响。一方面，有像 Marker Interface Pattern 这样的模式。 (基本上是一个空接口(interface))，这对您的代码几乎没有影响。另一方面，有类似 Abstract Factory Pattern 的模式。和 Builder Pattern ，这对您的整体设计有重大影响。

您的代码通过实现接口(interface)展示了基本的解耦。因此，如果它遵循某种模式，那么它将是“较小”模式之一。

Strategy Pattern您提到的是基于解耦代码。但策略模式的核心是你在程序运行时改变策略。一个例子是改变某些游戏(让我们选择星际争霸)的人工智能，以响应认识到对手明显更弱/更强，并且更具防御性/进攻性的行为将是有益的。您的代码似乎实现了一些网络服务(或者至少是进程之间的一些数据传输)。通常，您不会重新定义对象的传输方式，因此我不会将其称为策略模式。

正如您在评论中提到的，Template Method Pattern会合适的。您的服务器定义何时发送内容(或者至少，这是我想象的)并调用具体端点来委托(delegate)实际工作。

总的来说，用模式名称标记代码并不是目标。您应该为工作选择正确的工具。有些模式比其他模式更适合某些任务。有时，不遵循任何已知模式的解决方案甚至可能更优雅/可读/性能更高/无论您的指标是什么。在这种情况下，不要试图将您的解决方案压缩为一种模式，只是为了在其顶部放置一个大而奇特的名称标签(这通常会导致过度设计)。 Sometimes, simple code is more elegant than every pattern.