我已经构建了一个软件架构,现在我想知道它是否可以被认为与某些已知的设计模式相匹配:
所有图层都由多个包含小块逻辑的接口组成:
HasService
表示某个类包含某些EntityService
和E
类型的Q
实现。
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..
}
}
答案 0 :(得分:2)
首先,让我们提到有不同程度的模式。我不是在谈论类型(如创建,结构,行为......),而是对代码库的实际影响。一方面,有像Marker Interface Pattern这样的模式(基本上是一个空接口),对你的代码几乎没有影响。另一方面,有Abstract Factory Pattern和Builder Pattern等模式会对您的整体设计产生重大影响。
您的代码通过实现接口显示基本的解耦。因此,如果它遵循模式,它将是“较小”模式之一。
您提到的Strategy Pattern基于解耦代码。但战略模式的核心是在程序运行时更改策略。一个例子是改变某些游戏的AI(让我们选择星际争霸),以回应他们认识到对手明显更弱/更强,更具防御性/攻击性的行为是有益的。您的代码似乎实现了一些Web服务(或至少在进程之间传输一些数据)。通常,您不会重新定义对象的传输方式,因此我不会将其称为策略模式。
正如您在评论中提到的,Template Method Pattern适合。您的服务器定义何时发送(或至少,这是我的想象),并调用具体的端点来委派实际工作。
总体而言,使用模式名称标记代码不是目标。您应该为工作选择合适的工具。有些模式比其他模式更适合某些任务。有时,没有任何已知模式的解决方案甚至可能更优雅/可读/性能/无论您的指标是什么。在这种情况下,不要试图在模式中挤压你的解决方案只是为了在它上面有这个大的花式名称标签(这通常导致过度工程)。 Sometimes, simple code is more elegant than every pattern.