有 Java 编程相关的问题?

你可以在下面搜索框中键入要查询的问题!

java这是一种策略模式实现吗?

我已经构建了一个软件体系结构,现在我想知道它是否可以与一些已知的设计模式相匹配:

所有层都由多个接口组成,这些接口包含少量逻辑:

HasService表示类包含某种EQ类型的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调用访问的实际端点由以下接口组成:

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..
    }

 }

共 (1) 个答案

  1. # 1 楼答案

    首先,要提到的是,有不同层次的模式。我不是在说类型(如创造性、结构性、行为性……)但是对代码库的实际影响。一方面,像Marker Interface Pattern(基本上是一个空接口)这样的模式对代码几乎没有影响。另一方面,有像Abstract Factory PatternBuilder Pattern这样的模式,它们对您的总体设计有重大影响

    您的代码通过实现接口来显示基本的解耦。因此,如果它遵循一种模式,它将是一种“较小”的模式

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

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

    总的来说,用模式名标记代码不是目标。你应该为这项工作选择合适的工具。有些模式比其他模式更适合某些任务。有时,一个不遵循任何已知模式的解决方案甚至可能更加优雅/可读/性能/无论您的度量标准是什么。在这种情况下,不要试图将您的解决方案压缩成一种模式,而只是为了在上面加上一个大的花哨的名字标签(这通常会导致过度工程化)Sometimes, simple code is more elegant than every pattern.