第一本座的笔记本

抽象工厂和生成器模式常常被混淆，因为他们之间实在有很多的相似点，比如都是创建型模式，都隐藏产品具体细节，都向用户提供一个包含一系列接口的对象。 这个说法比较抽象。我们通过实现来看看为什么容易混淆。抽象工厂我们使用一个汽车生产来做例子。抽象工厂模式如下： 有一个抽象工厂类名为Factory,工厂的作用是生产车的不同部件。 有一个奔驰工厂BenzFactory继承了这个Factory，专门用来生产

Vector差不多是我用得最多的容器，原因嘛当然办为他好用了，动态数组的感觉用起来很方便。但这种方便是有代价的，不然为什么还需要定长数组呢。Vector的动态增长需要重新分配内存，然后将原有数据move过去，这其中有对象的构造、析构等等，这是vector主要的效率损耗。(迭代器失效的锅，内存重新分配也要背，内存变了，所有指针相关的全部失效)所以vector和数组扩张、容易减少相关的所有

C++调用Python在一些特殊的场景下有一定的价值。比如，要调用一个REST服务，c++本身做HTTP Client会很烦，如果使用Python脚本去调用服务，返回结果给c++端就可以绕开这个问题。因为最近在一个原型开发中遇到了这个问题，所以为了快速拿出东西来，我决定使用这种方法。使用效果一般，主要是太慢用来做demo还行，可能是我还没用好。官方文档https://docs.py

最近在学习中因为 #include <curl/curl.h> 出现错误 “无法打开源文件curl/curl.h”。顺着这条线索，一点儿一点儿的学习，发现远远不是用一个curl库这么简单。其实后来发现VS的NuGet程序包管理工具，确实非常好用，一键安装一堆依赖库。强烈建议要快速跑起来的使用。具体过程就是在项目解决方案右键选择NuGet 搜索curl安装即可。不使用NuGet工具的话就用

设计模式是一种经验的总结，有经验的面向对象设计者在不断的开发试错、总结中得到了一些面向不同场景不同需求的设计经验，经过不断的验证，基于这些经验的某种面向对象的设计风格被认为是某种意义上的最佳实践。 当然是不是真的有最佳实践这种东西呢，我个人觉得，在大部分时候，我们可以照搬某个基本的设计模式，应用到我们自己的项目中去，但是实际项目中，也会有很多问题，必须要根据实际的情况对这些模式进行一些变形。 所

将抽象与实现分离，使其双方独立变化是桥接模式的意图。当一个抽象类可能有多个实现时，通常用继承协调他们。抽象类定义对该抽象的接口，而具体的子类则用不同方式加以实现。但抽象和实现在这种设计下是绑定的，不能灵活的改变，利用和扩展。桥接模式的出现就是要解耦这种关系。场景桥接模式的重点在于抽象与实现的解耦合，所以设想这样一个场景。一个抽象接口的实例需要动态的根据需求具有不同的实现。这一点通过继承显然不能真正的

在语法上，构造函数调用虚函数当然是没有问题的。但是这种用法不一定能得到想要的结果，还会引发一些小问题。class Base {public: Base() { this->func1(); this->func2(); }; virtual void func1() { cout << "base::func1" << endl; }; virtual void func2

代理模式和装饰模式总是让人混淆，他们形式上确实非常像。代理模式结构： 实现： 有这样一种场景，一种特别庞大的组件需要在特定的时候被绘制出来，这种庞大的组件绘制了之后会造成系统的负担。 此时可以使用代理模式，在确定这个组件必须被绘制的时候，才通过代理，将这个组件绘制出来。class Component//普通组件{public: virtual void Draw();};c

理解适配器就明白什么是适配器模式，适配器模式本就来源于生活中适配器的启发。那么什么是适配器呢？。场景适配器的作用就是使用户能够通过统一的接口，复用已有的但接口不统一的功能。好吧，我承认这一句话比较抽象。有一个古老的问题，一只动物，看上去是羊，听上去是羊，那他就是羊。是真的吗？有一只狼，他想混进羊群，但是有放牧人看着他发现很难直接混进去。他找来了一张羊皮，披上这张羊皮之后，他成功的骗过了牧羊人的眼睛。

原型模式的特点就是用一个实例去创建新的其他实例。场景比如游戏里的商店卖装备，我去买装备，在设计这个装备商品的时候，当然是希望这件装备可以无限出售，不然的话我库存设置为多少好呢（当然可以有其他解决办法，但这里我们用原型模式）？ 使用原型模式，这件装备出售的时候就clone一件给玩家，这样商店就不用担心库存不够了，无论多少玩家买都应付得过来。 我个人使用原型模式就是这么做的，当然还因为一些其他动机，

我遇到一个应用需要做微服务化改造。这个应用包括分离度很高的前端和后端两部分。在我看来微服务是一个后端的概念，与前端没什么关系。对旧的应用进行微服务化改造主要集中在后端。并且原有系统分离程度很高的时候，要尽量沿用原有界面，一方面是节约时间，一方面顺从用户习惯。所以我遇到了这样一个问题，一个Qt应用，后端微服务化，前后端如何交互的问题：比如我现在开发了基于SpringCloud的REST服...