这个项目进行了之前项目的优化，项目对应的UML类图如图。
相较于之前的UML类图可以看到其复杂了一点，其实只是看这里的话会感觉没有什么优化，相反来说更复杂。但是这要结合QT的信号与槽机制来看。
在这个项目版本中，进行了对于原本heap类的解耦，将其解耦成了一个数据处理模块和渲染模块，俩个模块之间使用观察者模式来进行通信。在这里不是一个经典的观察者模式架构。这是因为在QT中存在一个观察者模式的上位结构，我通过使用这个模式来简化我们观察者模式的架构。
接下来对这个项目进行介绍。
有一说一，我确实没想到这个项目可以打赢复活赛。原本的项目的UML类图如下
在原本的项目中，我的功能模块heap类是强耦合的，在学了设计模式之后，我一直在想着能否将这个模块进行解耦，在有了一定的基础之后，我就开始了这个工作。
我的考虑是，将这个强耦合的功能模块解耦成俩个单独的模块，其中一个是用于数据处理的模块，另一个是用于图像渲染的模块。最后的成果就是那个新的UML类图。在新版本的项目中，我基本将数据模块和渲染模块进行了一次相对彻底的解耦，俩者通过观察者模式来进行连接。在QT中我是通过信号与槽机制来实现这里的观察者模式的。
在实现了这俩者模块的分离之后，我还遇到了一个问题，就是我的信号连接，必须存在俩者的示例对象的，但是我不想再去内嵌俩个模块中的任何一个内嵌到另一个模块中。所以在这里我考虑了另一种方法，使用一种结构性设计模式来进行架构。在这里就是我的heapManage类，这个类使用的设计模式是外观模式。
通过外观模式，我成功的将底层的实现逻辑给进一步的封装了起来，并且，我在这个外观模式类中提供了系列底层的接口用于功能的实现，这里由于设计问题这里的接口只是起到了一个参数传递的功能，不过也无所谓了。
其他模块的功能其实没有什么大的改动，从上面的俩个类图对比也可以看出来。有一说一，这个优化后的类图相较与优化前的类图真优雅吧。
总的来说，在这次代码架构优化中，遇到的最核心的启发就是学一个东西最好的方式就是问题驱动式的学习，通过一种内驱力来实现对于外部知识的内化。
下面给出代码仓库的地址，有兴趣可以自己去搓一遍，毕竟类图都已经给你了，整体的代码逻辑也不算复杂。