geomative/GeomativeStudio/.qoder/repowiki/zh/content/开发者指南/核心架构模式/核心架构模式.md

核心架构模式

**本文档引用的文件** - [GeoMative.cpp](file://cpp/Main/GeoMative.cpp) - [Global.cpp](file://cpp/Main/Global.cpp) - [ProManager.cpp](file://cpp/Managers/ProManager.cpp) - [DevManager.cpp](file://cpp/Managers/DevManager.cpp) - [ExecManager.cpp](file://cpp/Managers/ExecManager.cpp) - [GeoMative.h](file://h/GeoMative.h) - [ProManager.h](file://h/ProManager.h) - [DevManager.h](file://h/DevManager.h) - [ExecManager.h](file://h/ExecManager.h)

目录

1. 单例模式应用
2. 工厂模式实现
3. 观察者模式机制
4. 责任链模式应用
5. 设计模式优势分析

单例模式应用

在GeomativeStudio应用程序中，CGeoMativeApp类作为全局应用程序对象，通过继承MFC的CWinApp类实现单例模式。该模式确保在整个应用程序生命周期中只有一个CGeoMativeApp实例存在，从而集中管理全局资源和应用程序状态。

CGeoMativeApp类在Global.cpp文件中被声明为全局变量theApp，这是实现单例模式的关键。通过这种方式，应用程序的任何部分都可以通过theApp访问全局应用程序对象，而无需创建新的实例。这种设计确保了全局状态的一致性，并避免了资源的重复分配。

在GeoMative.cpp文件中，CGeoMativeApp的构造函数初始化了多个管理器指针，包括m_pTdManager、m_pProManager、m_pDevManager等，这些指针在InitInstance方法中被实际创建。这种延迟初始化的策略优化了启动性能，只有在需要时才创建相应的管理器对象。

CGeoMativeApp类还负责管理数据库连接、网络操作、设备管理等核心功能。通过将这些功能集中在一个全局对象中，应用程序实现了资源的统一管理和访问控制。例如，m_pConnection成员变量提供了对数据库的全局访问，而m_NetWorkOper成员变量则管理所有的网络通信。

Section sources

• GeoMative.cpp
• Global.cpp

工厂模式实现

工厂模式在GeomativeStudio中主要通过CProManager::GetDMS方法实现，该方法根据句柄创建和管理不同类型的管理对象。这种设计模式将对象的创建逻辑与使用逻辑分离，提高了代码的灵活性和可维护性。

CProManager类中的GetDMS方法是一个典型的工厂方法实现。该方法接收一个句柄参数，根据句柄的样式（style）创建相应的数据管理结构对象。如果对象已经存在于缓存中，则直接返回缓存的对象；否则，根据句柄样式创建新的对象并将其添加到缓存中。

classDiagram
class CProManager {
+GetDMS(DWORD dwHandle) CDataMngStruct*
+ShowProList(DWORD dwDevHandle, CListCtrl& proList) bool
+ShowTzList(DWORD dwProHandle, CListCtrl& tzList) bool
+CreateProjectInDB(DWORD& dwID) UINT
+CreateProjectInDev(DWORD dwID, CDevice* const pDev) UINT
}
class CDataMngStruct {
<<abstract>>
+GetID() DWORD
+GetStyle() UINT
}
class CProject {
+CProject(DWORD dwID, _ConnectionPtr& pConnection)
+GetProjectName() CString
+GetProjectLocation() CString
}
class CTestingZone {
+CTestingZone(DWORD dwID, _ConnectionPtr& pConnection)
+GetZoneName() CString
+GetZoneType() CString
}
CProManager --> CDataMngStruct : "creates"
CDataMngStruct <|-- CProject : "extends"
CDataMngStruct <|-- CTestingZone : "extends"

**Diagram sources **

• ProManager.cpp
• ProManager.h

Section sources

• ProManager.cpp
• ProManager.h

观察者模式机制

观察者模式在GeomativeStudio中通过MFC消息映射（DECLARE_MESSAGE_MAP）和自定义WM_消息（如WM_REFRESH、WM_SCHEDULE）实现组件间的松耦合通信。这种设计模式允许对象在状态改变时通知其他对象，而无需知道这些对象的具体类型。

在GeoMative.h文件中，CGeoMativeApp类使用DECLARE_MESSAGE_MAP宏声明了消息映射，这使得应用程序能够响应各种Windows消息。通过BEGIN_MESSAGE_MAP和END_MESSAGE_MAP宏，可以将特定的消息（如ON_COMMAND）映射到相应的处理函数。

自定义消息如WM_REFRESH和WM_SCHEDULE在应用程序的不同组件之间传递状态更新和调度信息。例如，在datamngframe.cpp文件中，OnRefresh方法处理WM_REFRESH消息，更新数据管理框架的视图。这种基于消息的通信机制使得组件之间的耦合度大大降低，每个组件只需关注自己感兴趣的消息。

sequenceDiagram
participant UI as "用户界面"
participant MainFrame as "主框架"
participant App as "CGeoMativeApp"
UI->>MainFrame : 用户操作
MainFrame->>App : 发送WM_SCHEDULE消息
App->>App : 处理消息映射
App->>MainFrame : 更新状态
MainFrame->>UI : 刷新界面

**Diagram sources **

• GeoMative.h
• datamngframe.cpp

Section sources

• GeoMative.h
• datamngframe.cpp

责任链模式应用

责任链模式在GeomativeStudio中应用于设备状态管理和任务执行流程。这种设计模式将请求的处理责任沿着一条链传递，直到某个处理者能够处理该请求。

在设备管理方面，CDevManager类通过GetDevice和GetDeviceByID方法实现了一条责任链。当请求获取设备时，系统会遍历设备链表，直到找到匹配的设备。如果设备未注册，系统会尝试通过序列号和MAC地址进行匹配。

在任务执行方面，CExecManager类的Exec2DRSPTest和ExecCERSPTest方法形成了一个责任链。这些方法负责执行不同的测试任务，每个方法都有明确的职责范围。如果一个方法无法处理某个任务，它会将请求传递给下一个方法。

flowchart TD
Start([开始]) --> CheckDevice["检查设备状态"]
CheckDevice --> DeviceValid{"设备有效?"}
DeviceValid --> |是| InitializeTest["初始化测试"]
DeviceValid --> |否| ReturnError["返回错误"]
InitializeTest --> ExecuteTest["执行测试"]
ExecuteTest --> ProcessResults["处理结果"]
ProcessResults --> UpdateStatus["更新状态"]
UpdateStatus --> End([结束])
ReturnError --> End

**Diagram sources **

• DevManager.cpp
• ExecManager.cpp

Section sources

• DevManager.cpp
• ExecManager.cpp

设计模式优势分析

GeomativeStudio中应用的这些设计模式显著提高了代码的可维护性和扩展性。单例模式确保了全局资源的一致性管理，避免了资源冲突和重复分配。工厂模式将对象创建逻辑集中管理，使得添加新的管理对象类型变得简单而安全。

观察者模式通过消息机制实现了组件间的松耦合通信，使得系统各部分可以独立开发和测试。这种设计大大降低了修改一个组件对其他组件的影响，提高了系统的稳定性和可维护性。

责任链模式为设备状态管理和任务执行提供了灵活的处理机制。通过将处理责任分解为多个步骤，系统能够更好地应对复杂的业务逻辑和异常情况。这种分层处理的方式也使得代码更易于理解和调试。

这些设计模式的综合应用，使得GeomativeStudio具有良好的架构特性：高内聚、低耦合、易于扩展和维护。当需要添加新功能或修改现有功能时，开发者可以专注于特定的组件或模式，而不必担心对整个系统造成意外影响。

Section sources

• GeoMative.cpp
• ProManager.cpp
• DevManager.cpp
• ExecManager.cpp