如果仅仅覆盖了一个toString的方法而使用继承的话，这个设计本身是有问题的。
如果猜的没有错的话，ContractModel是用在了持久层中的model，那个ContractQueryModel是用在业务层中的model，为了方便，某个开发直接把两者搞成了继承的关系。
个人其实非常反感这种数据和逻辑分离的模式，我比较喜欢如下方式：

Contract contract = new Contract();
contract.setName(...)
...
contract.save();
...
Contract other = Contract.find(...);
...

不确定你的问题是：“继承的意义”？还是“为什么ContractQueryModel只重写了toString方法”？

如果是不理解“继承的意义”？那我想，最基本的理解就是为了复用，可以看文档：

文档地址：Inheritance

如果你的疑惑是，为什么继承了半天，最后只重写了toString方法？

最主要的原因我想是因为作者想要满足开闭原则，想要一个新的toString方法，又不想对原代码ContractModel作修改。无论如何，关于细节，你应该直接和作者讨论，说不定他有更深层次的考虑。仅从你的代码片段里，我看不出更多内容了。

补充：

我个人理解，这不算是“代理模式”，原因是她不符合“代理模式”的基本特征，关于代理模式，看如下图解：

由此我们知道，代理模式下，代理类应该和被代理类实现相同接口，这里的ContractQueryModel不具备此特征。

最后我想谈谈对于设计模式的粗浅理解，所谓设计模式是一种解决特定问题的最佳实践范式，有些模式具备固定特征，有些则不具备。所以仅凭题主的几个简单的类，在脱离上下文的情景下，我很难判断他是哪种设计模式(我指那些不具备固定特征的)。

仅看名字作出以下猜测：
ContractModel是一个DTO，负责传输数据；
ContractQueryModel是一个查询参数对象，负责接收从Controller（或其他地方）传来的查询参数；
由于都是查询Contract，所以字段基本上是一样的，但为了以后扩展方便，所以这里用了继承的方式去实现。

但个人在实际应用中DTO和查询参数一般不是同一结构，DTO如题主所示，查询参数一般是DTO字段的复数形式，例如：

public class ContractQueryModel implements Serializable {
    private Set<Integer> templateCategaries = Collections.emptySet();

    private Set<String> names = Collections.emptySet();

    private Set<String> codes = Collections.emptySet();
    
    ...
}

另外，@菩提旭光 提到的里氏替换原则，可以看一下这个，里面有提到题主这种设计可能会有什么问题。

你们真逗, lz都不知道自己要问什么,你们还解答, 而且这问题还成了本周推荐, 奇葩啊