a

2026-07-03 16:05:30 +08:00
commit df489d5640
1101 changed files with 779140 additions and 0 deletions
@@ -0,0 +1,151 @@
+# 核心架构模式
+
+<cite>
+**本文档引用的文件**   
+- [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)
+</cite>
+
+## 目录
+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](file://cpp/Main/GeoMative.cpp#L56-L130)
+- [Global.cpp](file://cpp/Main/Global.cpp#L25-L26)
+
+## 工厂模式实现
+
+工厂模式在GeomativeStudio中主要通过`CProManager::GetDMS`方法实现，该方法根据句柄创建和管理不同类型的管理对象。这种设计模式将对象的创建逻辑与使用逻辑分离，提高了代码的灵活性和可维护性。
+
+`CProManager`类中的`GetDMS`方法是一个典型的工厂方法实现。该方法接收一个句柄参数，根据句柄的样式（style）创建相应的数据管理结构对象。如果对象已经存在于缓存中，则直接返回缓存的对象；否则，根据句柄样式创建新的对象并将其添加到缓存中。
+
+```mermaid
+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](file://cpp/Managers/ProManager.cpp#L154-L182)
+- [ProManager.h](file://h/ProManager.h#L30-L74)
+
+**Section sources**
+- [ProManager.cpp](file://cpp/Managers/ProManager.cpp#L154-L182)
+- [ProManager.h](file://h/ProManager.h#L30-L74)
+
+## 观察者模式机制
+
+观察者模式在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`消息，更新数据管理框架的视图。这种基于消息的通信机制使得组件之间的耦合度大大降低，每个组件只需关注自己感兴趣的消息。
+
+```mermaid
+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](file://h/GeoMative.h#L175-L176)
+- [datamngframe.cpp](file://cpp/Views/datamngframe.cpp#L299-L312)
+
+**Section sources**
+- [GeoMative.h](file://h/GeoMative.h#L175-L176)
+- [datamngframe.cpp](file://cpp/Views/datamngframe.cpp#L299-L312)
+
+## 责任链模式应用
+
+责任链模式在GeomativeStudio中应用于设备状态管理和任务执行流程。这种设计模式将请求的处理责任沿着一条链传递，直到某个处理者能够处理该请求。
+
+在设备管理方面，`CDevManager`类通过`GetDevice`和`GetDeviceByID`方法实现了一条责任链。当请求获取设备时，系统会遍历设备链表，直到找到匹配的设备。如果设备未注册，系统会尝试通过序列号和MAC地址进行匹配。
+
+在任务执行方面，`CExecManager`类的`Exec2DRSPTest`和`ExecCERSPTest`方法形成了一个责任链。这些方法负责执行不同的测试任务，每个方法都有明确的职责范围。如果一个方法无法处理某个任务，它会将请求传递给下一个方法。
+
+```mermaid
+flowchart TD
+Start([开始]) --> CheckDevice["检查设备状态"]
+CheckDevice --> DeviceValid{"设备有效?"}
+DeviceValid --> |是| InitializeTest["初始化测试"]
+DeviceValid --> |否| ReturnError["返回错误"]
+InitializeTest --> ExecuteTest["执行测试"]
+ExecuteTest --> ProcessResults["处理结果"]
+ProcessResults --> UpdateStatus["更新状态"]
+UpdateStatus --> End([结束])
+ReturnError --> End
+```
+
+**Diagram sources **
+- [DevManager.cpp](file://cpp/Managers/DevManager.cpp#L82-L90)
+- [ExecManager.cpp](file://cpp/Managers/ExecManager.cpp#L483-L613)
+
+**Section sources**
+- [DevManager.cpp](file://cpp/Managers/DevManager.cpp#L82-L90)
+- [ExecManager.cpp](file://cpp/Managers/ExecManager.cpp#L483-L613)
+
+## 设计模式优势分析
+
+GeomativeStudio中应用的这些设计模式显著提高了代码的可维护性和扩展性。单例模式确保了全局资源的一致性管理，避免了资源冲突和重复分配。工厂模式将对象创建逻辑集中管理，使得添加新的管理对象类型变得简单而安全。
+
+观察者模式通过消息机制实现了组件间的松耦合通信，使得系统各部分可以独立开发和测试。这种设计大大降低了修改一个组件对其他组件的影响，提高了系统的稳定性和可维护性。
+
+责任链模式为设备状态管理和任务执行提供了灵活的处理机制。通过将处理责任分解为多个步骤，系统能够更好地应对复杂的业务逻辑和异常情况。这种分层处理的方式也使得代码更易于理解和调试。
+
+这些设计模式的综合应用，使得GeomativeStudio具有良好的架构特性：高内聚、低耦合、易于扩展和维护。当需要添加新功能或修改现有功能时，开发者可以专注于特定的组件或模式，而不必担心对整个系统造成意外影响。
+
+**Section sources**
+- [GeoMative.cpp](file://cpp/Main/GeoMative.cpp)
+- [ProManager.cpp](file://cpp/Managers/ProManager.cpp)
+- [DevManager.cpp](file://cpp/Managers/DevManager.cpp)
+- [ExecManager.cpp](file://cpp/Managers/ExecManager.cpp)