一个显示模块的设计

场景： 单系统，多线程。一个线程生成数据，另外一个线程接收生成的数据，并调用显示库函数，将数据显示。

目的：在显示器中显示数据
库：嵌入式显示模块开发库
现有结构： 显示模块运行，整理为一个单独线程。它需要其他模块传递数据。


初步设想：
将整个显示模块设计为一个singleton单例类，两个线程都可以调用。一个线程用于调用显示接口，另外一个线程调用数据更新接口。两个线程之间的互斥，使用一个mutex来完成。


实现：
仅仅将全局变量设计为一个singleton单例模式，两个线程采用一个mutex来进行互斥，对数据进行保护。


----------------------
评价：
简单的模块


设计原则：
如果需求变动，就需要修改类。
一般容易变动的代码是 数据更新接口createOverlayData，当现实的数据有需求变化时，这块的代码就需要改动。


原因：本实例没有抽象接口。仅仅是一个简单的对象详细。类似于一个全局变量，并且由两个线程使用。


设计原则2： 简单情况下，不用抽象，直到第一个需要抽象的需求出现。

对修改关闭，对扩展开发。这个原则没办法使用。

目前，这个需求还没出现。

--------------------------

若不采用mutex互斥的方式进行数据传递。就需要一个observer模式，进行数据更新。两个线程之间的数据和运行基本上互不干扰，额外的开销就是一个缓存队列。

observer模块，增加的代码复杂度，不过能将结果数据供多个模块使用（目前，没这个需求）

若使用observer模式，singleton模式的是可以保留的，无论如何变化，显示控制端一般只需要一个对象管理即可。

可能的抽象接口：

还没想出来

--------------------------
6个设计原则：
1. 对修改关闭，对扩展开发。
2. 基类出现的地方，一定可以用子类来替换。子类与基类的关系
3. 依赖抽象，而不是依赖实现。抽象就是基类的方式，实现就是子类的方式。
4. 提供小接口，而不是大接口。接口隔离原则
5. 尽量使用组合，聚合，而不是继承。复用的方式。
6. demeter原则，软件实体间，尽量少交互。


这里尽量考虑了5,6原则，其他原则都没能用得上。（每写一个模块，就考虑何时、如何使用这些原则）
何时能很快地抽象接口。