数据库

​ 在这一个分类中，将记录我的数据库学习过程，主要是个人在学习15-445网课的思考，敬请期待吧，没什么好说的，让我们开始吧。之后有什么要补充的将会在这篇文章中进行补充(如果没忘的话)。

Modern SQL

数据库系统

模版

​ 模版是C++中一个相对重要的特性了，直接来吧

类模版

​ 由于这种东西还是得上手去敲，所以我们在这里对很多内容将会进行简化。

​ 模版这种东西最直观的作用就是进行方法与所使用的数据类型之间的解耦，使得在设计方法时能够更加专注于特定功能的方法的构建而不必要去关注所使用的数据类型。

该篇是在对于std标准库的迭代器初步接触时所写，只是一些基本的常识以及对于部分类知识的回顾

迭代器

初步了解

​ 迭代器本身其实并没有什么特殊的，我们需要先从它存在的意义开始了解，对于一个迭代器，其的存在意义就是为一系列的容器提供一个通用的接口。通过这个接口，我们能够实现一系列的操作。

高精度

加法

​ 高精度的加法主要是逐位的加，在大于10时向前进位即可，需要注意的就是需要一开始进行位的补齐，以方便后续的运算。

​ 主要就是以下几个要点:

• 对于进行运算的俩个字符串的位进行补齐，统一之后的位计算
• 对于每个位进行简单加法运算的时候需要注意进位的时机
• 对于运算后可能的额外位别给忘了

数据库环境构建

​ 对于一个普通的java项目，想要实现对于数据库操作的支持，及连接数据库以及对于数据库的增删查改等。需要一下几个操作(可能存在的操作)

​

中介者模式

定义

​ 用一个中介对象来封装一系列的对象交互。中介者使得各对象不需要显示的相互引用，从而是其耦合松散，而且可以独立地改变他们的交互。

迭代器模式

定义

​ 提供一个方法顺序·访问一个聚合对象中的各个元素，而又不需要暴露该对象的内部表示。

命令模式

​

定义

​ 将一个请求封装成一个对象，从而让你使用不同的请求把客户端参数化，对请 求排队或者记录请求日志，可以提供命令的撤销和恢复功能。

粗略理解

​ 奇怪，我对于这个命令模式就是有点疑惑，我就是不知道它到底是一个什么情况。让我简单先敲一遍，兴许就能理解问题了。

​ 先举一种简单的现实生活中的命令模式来进行理解。就是餐馆的一个点餐系统。在现实生活中，你需要去思考你到底要选择那一道菜，然后你需要去考虑把你选择的这些个菜单送给服务员，然后服务员会将这些菜送给后厨，然后用户就只需要等待。

​ 但是我们有没有考虑过没有服务员这种情况呢，如果没有服务员，我们就需要去直接与后厨进行对接。这想想都不现实对吧。在程序设计中，这其实也是一种哲学。当我们程序设计得在用户实现一个功能直接调用底层的api时，这种设计是极其糟糕的。当然我这句话的描述有点问题，主要就是这里的用户是指使用设计好的程序的用户，而不是程序设计阶段的。

​ 这种没有服务员的情况其实就是一种用户请求与具体实现之间的强耦合。再举一个甲乙方的例子来看。当甲方下发一个需求的时候，具体的乙方一般是不会看到这个甲方来直接去找到对应的员工来实现对应的功能的。相反，我们通常是把这个命令发送给乙方的对接部门，然后通过一些处理，这些命令会被分包并且下发给对应的实现部门。

​ 我好像有点理解了。所谓的命令模式，要实现的就是一个命令发出者与命令实现之间的一个解耦。这时就需要我们去进行在中间的一层代理，在点餐系统中这是服务员。在项目对接中这个可能是项目经理。但是不变的是，在这种对接中，我们解开了命令发出者和命令执行者之间的强耦合。

​ 通过这种解耦，客户将不用去后厨直接找到对应的厨师进行下单。只需要更具餐馆的规范去进行我们需求的发出，服务员负责添加这些需求到对应的列表中，而服务员接下来还负责将这些个需求按一定顺序发送给对应的后厨部门进行完成，这种分层式的设计使得用户不再需要去了解底层复杂的东西，只需要去了解餐馆提供的简单的菜单即可，其他的逻辑由下面的命令转发者和命令执行者进行操作。

​ 到这里我其实明白了之前的误解。在理解命令模式中，不要在一开始就想得太多。类似与服务员这种消息转发者能够处理一些非常简单的消息转发，就比如用户想要那道菜，服务员就通知后厨做那道菜。除此之外，用户可能还会点套餐，这是一套复杂的命令，可能需要多个处理动作配合使用，这个也是服务员这个中间层需要做的事，但是一开始我们并不需要去拘泥在这里，可以从简单的地方出发。

​ 还有，当我们需要添加菜单时，我们至少也需要去为对应的后厨添加对应的处理动作，这也是我之前存在疑惑的地方，不过现在也解开了一点了。

总的来说，我现在感觉命令模式的核心在于:命令的处理与转发，通过引入一个具有转发行为的类来进行解耦

在最简单的命令模式中，这个转发可以是一个不做任何处理的转发，其他复杂情况再说，现在先从简单的入手。

代码实例

​ 在我看来，理解命令模式中，去看代码甚至比看UML类图更加重要。至少我第一次看的视乎类图根本看不懂它在说什么。

命令

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

// Receiver: 后厨
class Kitchen {
public:
    void prepareDish(const std::string& dish) {
        std::cout << "Kitchen is preparing: " << dish << std::endl;
    }
};

// Command: 命令接口
class Command {
public:
    virtual ~Command() = default;
    virtual void execute() = 0;
};

// ConcreteCommand: 具体命令类
class PrepareDishCommand : public Command {
private:
    Kitchen* kitchen;
    std::string dish;
public:
    PrepareDishCommand(Kitchen* k, const std::string& d) : kitchen(k), dish(d) {}
    void execute() override {
        kitchen->prepareDish(dish);
    }
};

​ 这里的几个类就是命令模式中的基本单位:命令的基本构成。在一个具体的命令中，需要包含这个命令具体的执行部门，所以这里保留了一个后厨的一个指针，用于进行执行部门的指定。我猜想，如果在后期需要对这个后厨部门进行划分，会将这个执行部门进行派生，至于继承还是聚合组合，那不是我们现在考虑的问题。

转发者

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

// Invoker: 服务员
class Waiter {
private:
    std::vector<std::shared_ptr<Command>> orders;
public:
    void takeOrder(std::shared_ptr<Command> command) {
        orders.push_back(command);
    }
    void sendOrders() {
        for (const auto& order : orders) {
            order->execute();
        }
        orders.clear();
    }
};

​ 可以看到，这里的转发者维护了一个命令队列，所有的客户给出的命令将会储存在这个队列中。我们还可以观察到这里的命令实际执行情况，其实就是一次程序控制流的转移，将当前的执行权限交给命令类进行自我的执行来实现对应的功能。

​ 这里当然还可以进行一系列的扩展，就比如进行消息的撤销等操作，可以自行添加。

​ 总的来说，这里的转发类重要的是这里的命令处理方法。通过储存客户端发出的所有命令，在适当的时机通过自身设定的命令执行顺序来进行对应的执行。而这里的执行，就跟很多设计模式一样，实际上就是进行一次程序控制流的转移，将程序控制流从当前的中转类转移到对应的命令处理程序中。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

// Client: 客户端
int main() {
    // 创建接收者
    Kitchen kitchen;

    // 创建具体命令
    auto steakCommand = std::make_shared<PrepareDishCommand>(&kitchen, "Steak");
    auto pastaCommand = std::make_shared<PrepareDishCommand>(&kitchen, "Pasta");

    // 创建调用者
    Waiter waiter;
    waiter.takeOrder(steakCommand);
    waiter.takeOrder(pastaCommand);

    // 服务员发送订单
    waiter.sendOrders();

    return 0;
}

​ 这里其实就没有什么好说的，需要注意的是，在命令模式中，我们需要在程序一开始进行所有的命令的初始化，之后我们所有发出的命令本质上其实就是保留了一份对应的指针。当然，你可以在每次调用时都进行副本的一次创建，不给你也应该知道这种模式的坏处。

下面给出一个不是很美的UML类图，我自己都没去看()

UML类图

​ 在接下来的QT中，我将会是一个相对无厘头的形态，属于是看到哪学到哪，并且大部分时间不会搓代码，只在之后使用一俩个相对不错的项目来进行熟悉。