章登宇

文件读写可以不用系统api用 fstream吗

> 理想情况下是做一个对应于OSAPIWrapper的GUIWrapper类，把GUI包装起来，然后Workflow只管逻辑，与GUI的互动由GUIWrapper对象来解决。 想了很久，觉得我们对【业务流程类】这个词的理解可能有所不同。 我认为，【业务流程类】不应该管【业务逻辑】。【业务逻辑】应当由核心类来完成。 【业务流程类】是核心类与 GUI 类的桥梁，仅此而已。

Workflow 抽象类还可以优化。 workflow.h ```cpp //此区域声明核心类 class Core; //Workflow 类 class Workflow { private: //此区域写核心类 Core* core; public: //伪构造函数和伪析构函数 void create(); void destroy(); //此区域写 on……()的函数 void onUseCore(); //此区域写 GUI 函数 virtual...

不好意思那个伪析构函数踩着 delete 关键字了。手机码字没有高亮，疏漏请见谅。

> 【业务逻辑】=时刻监督并控制程序下一步该干什么（抽象意义上），比如登录账户是Admin，那么下一步就是进入Server端模式，否则进入Client端模式；又如老师点击【点名】按钮，下一步就是生成一个随机数，给对应的Client发送点名信号。 >Workflow类只负责到这一步，我称为业务逻辑。 我认为，Workflow 连这一步都不必做。考虑到移植时 UIWorkflow 的代码需要重写，里面的东西越少越好。这也是上面的代码中“接口单行实现”的意义。 我理解的 Workflow 只负责告知某一个核心类（比如 LoginBot）点击了登录按钮。 ```cpp void Workflow::onLogin() {return this->loginbot->onLogin();} ``` 判断用户是学生还是教师还是管理员，以及判断之后进入的客户端模式，以及关闭登录窗口，打开新窗口，都应该在核心类的成员函数 LoginBot::onLogin() 中实现。这样才能最大程度实现核心类和 GUI 解耦，并最大程度降低移植的工作量。 一个困惑 Workflow/UIWorkflow 是把一个类拆成了两个类，UI 为实，Core 为虚。也就是说，这两个类完全可以反过来写。（继承关系可以反） 但是拆分类之后，实的部分更贴近 main() 函数，虚的部分拥有完整的函数表。这是不对称的，但我始终想不明白怎样写更优。...

> 分歧的本质在于“类叫什么名字” 确实是，之前的讨论是类名字的问题。下面我想提出一种方式，“消灭”掉管杂事的类。 之所以要有一个管杂事的类，是因为核心类“需要知道当前程序的状态”。 Workflow 接口的设计是为了： Core 调用 GUI GUI 调用 Core 但它同时也实现了： Core 调用 其他Core GUI 调用 其他GUI 因此，为了保存程序状态，可以在 Workflow 中创建一个核心类 State ，然后由需要获取程序状态的核心类通过 Workflow 指针间接获取。 这样一来，消灭掉管杂事的类，降低代码的“恶心”程度。

这里先阐述一下我执意要“消灭”管杂事的类的原因。 ———————— 设想一个场景： 程序员 A 开发了一个类 Net，用来进行 TCP 通信。 显然，这个类与 GUI 无关，不需要保有 Workflow 指针。 这个 Net 类称为底层核心类。 程序员 B 正在开发一个类 SingleFrame，这个类利用 Net 类从网络上获取一张图像，并显示到窗口中。 这个类处理“显示一张图像”的业务逻辑，因此需要保有 Workflow 类的指针，同时需要有一个 Net 类的成员变量。 这个 SingleFrame...

按照这个[类图](https://github.com/profthecopyright/Thunder_Class/tree/master/doc/%E7%B1%BB%E5%9B%BEplantUML.png)的架构确实更好。 之前提出的那个方案的出发点是方便各个业务逻辑单独开发，便于多个开发者共同参与。 我们的设计都需要通过一个顶层类把各种业务逻辑整合到一起。我一开始选择了 Workflow，但加一层 User 应该是更好的选择。 确实，选择 Workflow 作为顶层类并不是很好的选择。前几条 comment 中希望让 Workflow 做的事情，其实是我希望顶层类做的事情。 由于此前开发GUI把 UIWorkflow 作为顶层类的惯性思维（GUI并不需要复杂的逻辑），我把 Workflow 选择作为顶层类确实是一种失误。 那么在我发的上一条 comment 中，我希望的对 Workflow 的操作，实际上是我希望的对顶层类的操作。（由于 User 类又分了三种环境下的具体实现，这些操作又可能是我希望的对 ClientUser类的操作） 因此，Status 下沉到 User 当然是正确的做法。...

>具体User怎么实现具体的逻辑，可能借助成员函数，也可能如你所说，把具体的业务功能分拆到相应的LoginBot或者相应的各种XXBot类中，各Bot由User统一维护（其实函数太多的话拆分是个自然而然的事情）。 有些时候一些业务功能并不需要和其他功能共享状态。比如，需求里提到了密码错误三次退出程序。这个密码错误的次数只有 LoginBot 需要用到。这也是我个人倾向于对象实现而不是直接在 User 的成员函数的原因。

上面讨论了项目架构的类的关系。 下面我想提出关于数据结构的存放的问题。 在上面的 GUIAdaptor 中有一个接口 addShowUsers(string, string, string, string) 我们肯定希望用一个结构体把 id，用户名，密码，身份这四个数据打包起来，也方便日后的拓展。 由于要求中禁止 GUI 类直接访问“其他类”，这些数据的打包只能通过结构体来实现。 那么问题来了，下面这段代码应该写在哪个文件中？ ```cpp typedef struct { string id; string name; string password; string role; } studentInfo; ```...