在分析openharmony的HDF驱动框架时我们会发现用了很多面向对象的思想，例如类继承、接口、单例类等，本来应该是好事情，**但使用时对象之间的关系交错复杂，不太符合linux内核分层分模块的思路，导致整体理解起来比较困难，**再加上"C/S设计模式”和“观察者设计模式"更导致系统理解起来比较麻烦，本文便针对C/S设计模式和单例类这个问题做梳理。

C/S设计模式和单例类

通过对HDF框架的梳理我们可以得到下图的关系，我们可以看到几个关键的代码块(Block),例如设备管理者服务(DevmgrService)、设备服务管理者(DevSvcManager)以及设备宿主服务(DevHostService)都有客户端、接口、实例主体这三个角色相关联。本文的目的是介绍此种方法的"道"而非"术"(在总结一篇术的文章，但是篇幅巨大，没法看，只能一点一点的先拆成一部分一部分的),所以只会单拎出一个代码块来进行说明，让大家了解这种应用方法。
✒️上图中设备宿主服务并没有使用单例模式,业务上此对象时需要建立多个的，放在此处主要为了说明C/S这种模式。

下面单独针对设备管理者服务(DevmgrService)进行说明

通过对代码的梳理可得代码流程如下图所示，由此可知此函数DevmgrServiceGetInstance的作用为创建DevMgr单实例对象，并为此对象设置好了具体的实现方法。

为了更好的观察DevMgr实例的具体方法我们可以参看IDevmgrService对象的类图，由图中标号①与标号②中我们可以发现实际创建的对象为单实例的DevmgrService类型(采用的static类型的对象)，而接收的对象(即返回值，标号②处)为IDevmgrService类型，由下面类图中的结构可知返回IDevmgrService类型相当于返回的单实例对象DevmgrService的super成员，可直接使用对应的接口函数。

**在驱动框架需要使用DevmgrService提供对应的服务时，可通过DevmgrServiceClntGetInstance函数获取设备服务管理客户端(DevmgrServiceClnt)的实例，该实例包含一个指向IDevmgrService对象的指针，通过该指针可以使用DevmgrService提供的服务，即设备管理接口。**客户端可以调用设备管理服务提供的功能，即C/S设计模式。

在分析时可能有码友会有一个困惑，当客户端的成员变量只有一个接口对象时，获取的对象又为单实例，此次返回的实际就是设备管理者服务(DevmgrService)实例本身,两者获取的函数几乎相同(如下图)，那**为何不直接调用服务本身呢？**例如直接舍弃DevmgrServiceClnt，直接使用DevmgrService。

关于这个问题我们相信如果直接使用DevmgrService本身应该也是可以实现的，但是职责不够清晰，扩展性差。通过下图(左边客户端，服务本身)来看他们分别提供的方法

DevmgrServiceClnt提供的方法如下:

1. DevmgrServiceClntAttachDevice：将设备（通过IHdfDeviceToken接口表示）附加到设备管理服务中。这通常意味着在系统中注册设备，使其可被管理和使用。
2. DevmgrServiceClntDetachDevice：从设备管理服务中分离（注销）指定设备ID的设备。
3. DevmgrServiceClntAttachDeviceHost：将一个设备主机（通过IDevHostService接口表示）和主机ID附加到设备管理服务中。设备主机可能是一个硬件或软件组件，负责一组设备的通信和管理。

而DevmgrService提供的方法如下:

1. DevmgrServiceStartService：启动设备管理服务，使其开始监听和处理设备相关的请求。
2. DevmgrServiceConstruct：构造（初始化）设备管理服务实例。这个函数会分配必要的资源、初始化接口等。
3. DevmgrServiceCreate：创建一个设备管理服务的实例。这个函数会返回一个HdfObject类型的对象，这是一个通用的对象框架，用于HDF（Hardware Driver Foundation）系统中的对象管理。
4. DevmgrServiceRelease：释放设备管理服务实例，进行资源清理。
5. DevmgrServiceGetInstance：获取设备管理服务的实例。
6. DevmgrServiceLoadLeftDriver：加载驱动程序。

由上可得出客户端主要是为了实现Manager域与Host域(设备)之间的有效通信和管理，而服务主体主要是实现对服务本身的管理。