此代码是Adapter模式的示例吗?

时间:2019-01-16 15:07:21

标签: java oop design-patterns adapter

PageInfo类

3

ResponseDto类

x

PageResponseDto类

public class PageInfo<T> implements Serializable {
    private static final long serialVersionUID = 1L;
    private int pageNum;
    private int pageSize;
    private int size;
    private int startRow;
    private int endRow;
    private long total;
    private int pages;
    private List<T> list;
}

使用

public class ResponseDto<T> implements Serializable {

    private String msg = "success";

    private int code = SUCCESS;

    private T data;
}

因为系统具有统一的返回类'ResponseDto',所以我想将PageInfo类转换为ResponseDto。因此编写了此代码。 此代码可以称为适配器模式吗?如果不是,那么此代码是否使用设计模式?还是应该将这种转换称为什么?

1 个答案:

答案 0 :(得分:3)

当前设计

按目前的代码,不会实现适配器模式。就众所周知的设计模式而言,此代码无法满足我所知道的任何代码。相反,下面的设计使用了基本的软件原理:继承和伪委托。

uml diagram

您的目标是“将PageInfo转换为ResponseDto”。我假设您的意思是您想传递一个封装并委托给PageInfo类的ResponseDto实例。

之所以不是适配器模式的示例,是因为当前没有ResponseDto独有的接口。实际上,它根本没有接口,也没有委派给PageInfo-问题1。

适配器模式专门用于封装不同的接口。


注释/建议/问题:

  • PageResponseDTO当前违反了Demeter定律;它对PageInfo的内部结构了解得太多。
  • PageInfo通过揭示其整个内部结构来破坏封装。
  • 除了使用PageResponseDTO复制PageInfo的所有内容外,为什么不保留对PageInfo实例的引用,并在必要时委托给它呢?
  • 您总是可以复制委托人的界面而不是透露它,但是,如果您发现自己复制了太多的功能接口,请考虑公开它。在重构中,马丁·福勒(Martin Fowler)分别将此称为封装委托和消除中间人。