Java Sudo策略模式的缺点

我正在从事一个项目，在这个项目中，我需要调用许多不同的服务，并希望尽可能多地抽象出公共逻辑。更重要的是，我还想返回自定义对象，而不是像json这样的东西。当我设计了一种方法来实现这一点时，我得到了一个范例，它让我想起了一个战略模式，但我认为它并不适合。我想知道在我这样做的过程中是否存在任何设计缺陷或危险

基本上，我创建了一个抽象类（

ServiceCall

），它包含调用服务的通用逻辑（拥有一个internet客户端并从所需的服务获取json响应）。这一切都是通过公共方法

调用（映射参数、映射头）

完成的。抽象类还定义了两个abstrach方法：

createCustomDTO（映射参数、映射头）

和

parseResponseToObject（字符串json）

。我马上解释一下这些的目的

对不同服务的每次调用都将使用一个类来创建，该类扩展了

ServiceCall

，并创建了抽象方法的实现

createCustomDTO

将创建一个自定义对象，其中包含调用服务所需的所有信息（url和标题）

parseResponseToObject

将获取一个json响应，并将其转换为稍后在代码中使用的java对象

下面是我所做工作的一个简单实现

服务呼叫

public abstract class ServiceCall {

    protected abstract Object parseResponseToObject(String json);

    protected abstract CustomServiceDTO createDTO(Map<String, String> keys,
        Map<String, String> headers);

    public Object call(Map<String, String> params, Map<String, String> headers) {

        // create and configure a CustomServiceDTO to call services with
        CustomServiceDTO dto = createDTO(params, headers);

        try {
            // make the service request
            String json = getServiceResponse(dto);
        catch (Exception e) {
            return new CustomServiceError(e);
        }

        // parse the response into the desired java object
        Object response = parseResponseToObject(json);
        return response;
    }

    private String getServiceResponse(CustomServiceDTO dto) {
        // use common logic to call the service using the information provided
        // by the dto

        String dummyResponse = "{\"prop\":\"value\"}";
        return dummyResponse;
    }
}

公共抽象类ServiceCall{
受保护的抽象对象parseResponseToObject（字符串json）；
受保护的抽象CustomServiceDTO createDTO（映射键，
地图标题）；
公共对象调用（映射参数、映射头）{
//创建并配置CustomServiceDTO以调用服务
CustomServiceDTO dto=createDTO（参数、标题）；
试一试{
//提出服务请求
字符串json=getServiceResponse（dto）；
捕获（例外e）{
返回新的CustomServiceError（e）；
}
//将响应解析为所需的java对象
对象响应=parseResponseToObject（json）；
返回响应；
}
私有字符串getServiceResponse（CustomServiceDTO dto）{
//使用公共逻辑使用提供的信息调用服务
//由dto
字符串dummyResponse=“{\“prop\”：\“value\”}”；
返回Dummy响应；
}
}

采样实施

    public class AddressCall extends ServiceCall {

    @Override
    protected Object parseResponseToObject(String json) {
        return new Address(json);
    }

    @Override
    protected CustomServiceDTO createDTO(Map<String, String> keys, 
        Map<String, String> headers) {
        CustomServiceDTO dto = new CustomServiceDTO();
        dto.setUrl("www.getMyDummyAddress.com/" + keys.get(0) + "=" + keys.get(1));
        dto.setHeaders(headers);
        return dto;
    }
}

公共类AddressCall扩展了ServiceCall{
@凌驾
受保护对象parseResponseToObject（字符串json）{
返回新地址（json）；
}
@凌驾
受保护的CustomServicedToCreatedTo（映射键，
地图标题）{
CustomServiceDTO dto=新的CustomServiceDTO（）；
setUrl（“www.getMyDummyAddress.com/”+keys.get（0）+“=”+keys.get（1））；
dto.setHeaders（headers）；
返回dto；
}
}

我看到的主要缺点是从不直接调用

createCustomDTO

和

parseResponseToObject

有点奇怪

对我来说，主要的优势是易于使用，并且可以将响应作为java对象返回

---

我真正想知道的是，这个范例还有其他问题或缺点吗？代码很好，但我承认它似乎与java通常的使用方式有点不同。

这与java通常的使用方式没有什么不同，这被称为设计模式

---

它非常常见，除了使用Object，Object最好用泛型类型代替。

感谢您的见解。我还没有听说过模板方法。该链接也非常有用，因为它既解释了它的优点，又链接到了一篇批评该模式的博客文章-