发表于 | 更新于 | 分类于

目的

定义一个用于创建对象的接口，让子类决定实例化哪一个类。使一个类的实例化延迟到其子类。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Class Creator
{
Public:
    Virtual Product* Create(ProductId id);
};

Product*Creator::Create(ProductId id)
{
    If(id ==MINE) return new MyProduct();

    If(id ==YOURS) return new YourProduct();

    Return 0;
};

发表于 | 更新于 | 分类于

目的

为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
Class Scanner
{
Public:
    Scanner(istream&);
    Virtual ~Scanner();

    Virtual Token& Scan();
Private:
    Istream& _inputStream;
};

Class Parser
{
Public:
    Parser();
    Virtual ~Parser();
    Virtual void Parse(Scanner&, ProgramNodeBuilder&);
};

//外观
Class Compiler
{
Public:
    Compiler();
    Virtual void Compile(istream&, BytecodeStream&);
};


//可以传入特定对象
Void Compiler::Compile(istream& input, BytecodeStream& output)
{
    Scanner scanner(input);
    ProgramNodeBuilder builder;
    Parser parser;

    Parser.Parse(scanner, builder);

    RISCCodeGenerator generator(output);
    ProgramNode* parseTree = builder.GetRootNode();
    parseTree->Traverse(generator);
};

发表于 | 更新于 | 分类于

目的

用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。

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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
Class MazePrototypeFactory :public MazeFactory
{
Public:

    MazePrototypeFactory (Maze*, Wall*, Room*, Door*);

    Virtual Maze* MakeMaze() const;
    Virtual Room* MakeRoom(int) const;
    Virtual Wall* MakeWall() const;
    Virtual Door* MakeDoor() const;

Private:
    Maze* _prototypeMaze;
    Room* _prototypeRoom;
    Wall* _prototypeWall;
    Door* _prototypeDoor;
};

 

MazePrototypeFactory::MazePrototypeFactory (Maze* m, Wall* w, Room* r, Door* d)
{
    _prototypeMaze = m;
    _prototypeRoom = r;
    _prototypeWall = w;
    _prototypeDoor = d;
};

Wall* MazePrototypeFactory::prototypeWall()
{
    Return prototypeWall->Clone();
};

 

//使用基本迷宫构建的原型进行初始化。

//普通的
MazePrototypeFactorysimpleMazeFactory(new Maze, new Wall, new Room, new Door);

//Bombed
MazePrototypeFactorybombedMazeFactory(new Maze, new BombedWall, new RoomWithABomb, new Door);

发表于 | 更新于 | 分类于

目的

保证一个类仅有一个实例，并提供一个访问它的全局访问点。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Class Singleton
{
Public:
    Static Singleton* Instance();
Protected:
    Singleton();
Private:
    Static Singleton* _instance();
};

 

Singleton*Singleton::_instance = 0;


Singleton*Singleton::Instance()
{
    If(_instance == 0)
    {
        _instance = new Singleton;
    }
    Return _instance;
};

发表于 | 更新于 | 分类于

|| |创建型 |结构型 |行为型|
|范围 |类 |Factory Method(工厂方法) |Adapter(类)(适配器) |Interpreter(解释器)|
|| |Abstract Factory(抽象工厂) Adapter(对象)(适配器) |Template Method(模板方法)|
|| |Builder(生成器) |Bridge(桥接) |Chain of Responsibility(职责链)|
|| |Prototype(原型) |Composite(组成) |Command(命令)|
|| |Singleton(单件) |Decorator(装饰) |Iterator(迭代器)|
|| ||Facade(外观) |Mediator(中介者)|
|| ||Flyweight(享元) |Memento(备忘录)|
|| ||Proxy(代理) |Observer(观察者)|
|| |||State(状态)|
|| |||Strategy(策略)|
|| |||Visitor(访问者)|

发表于 | 更新于 | 分类于

人们普遍认为在管理大型系统的复杂性方面，面向对象范型存在潜在优势。但是，如果你认为在大型项目中，只要使用C++就会确保成功，那就完全错了。
面向对象范型声名狼藉，因为面向对象范型比相应的面向过程技术需要更多的设计工作和悟性。通过虚函数改变内部行为的能力会使类不变量无效，这些类不变量对于纠正性能是必不可少的。而且，贯穿一个面向对象系统的控制流路径潜在数量可能会爆炸性地增大。
当程序规模变得更大时，不同属性的效力就开始起作用。
例如：

1. 循环依赖

2. 过度的链接时依赖

对象的好处之一是在需要时很容易添加功能。面向对象范型这种几乎诱人的特性让许多一丝不苟的开发人员把高效、考虑完善的类转换成具有大代码的“庞大恐龙”-绝大多数客户端没有使用大部分的类。
应用特别细致的String类编写的”Hello World”程序,竟然产生了1.2MB的可执行文件长度。

3. 过度的编译时依赖

用C++开发多文件程序，更改一个头文件可能会引起许多编译单元重新编译。随着系统的继续开发，重新编译整个系统所需的时间在逐渐增加，编译单个编译单元的时间也在逐渐增加。

4. 全局名字空间

全局标识符的广泛应用可能会引发问题。一种显而易见的危险是这些名字可能会存在冲突。结果是，若不修改名字冲突，独立开发的系统部件将无法集成到一起。对于拥有数百个头文件的更大型项目来说，即使查找一个全局名字的声明也是一件困难的事情。

5. 逻辑设计和物理设计

大部分关于C++的书中只讲述了逻辑设计。逻辑设计是指从属于诸如类、运算符、函数等语言结构的那些设计。
物理设计解决的是与一个系统物理实体(像文件、目录和库等)密切联系的问题和物理实体之间的编译时依赖或者链接时依赖之类的组织问题。

6. 重用

重用意味着耦合。
重用通常是一个好方案，但是为了成功重用，组件或子系统一定不要与一大段不必要的代码绑定在一起。也就是说，必须能够重用所需要的系统的一部分，同时不必链接系统的其他部分。
并不是所有的代码都可以重用，试图实现过多的功能或者为实现对象进行鲁棒错误检测，可能会增加不必要的开发和维护成本，同时也会增加可执行代码的大小。

发表于 | 更新于 | 分类于

CMDB建设：负责底层基础设施管理，包括物理机、虚拟机、docker容器管理；
制定各种规范，进行多数据中心建设，业务上异地双活

DevOps平台：统一研发入口，可以调度底层各种工具，实现对应功能。
运维、配置管理、Java技术人员

集成各种语言的工程模板、git代码管理、jenkins持续集成、自动化接口和性能测试、发布流水线和金丝雀分析、域名解析、弹性扩缩容

负载均衡
全局负载均衡（Global Server Load Balance, GSLB）
服务器负载均衡（Server Load Balance, SLB）

信息安全技术架构

微服务平台技术架构

服务安全
事务服务
消息服务
配置中心
注册中心
调度中心
工作流服务
规则引擎及风控
搜索服务
流量控制
报表服务
缓存管理
故障演练
全链路压测
容量规划
在线调试zdebugger

测试平台技术架构

单元测试

接口测试
自动化测试

性能测试
全链路压测

数据平台技术架构

数据集成
存储计算
数据服务
数据分析
数据安全

展望
业务隐藏
弹性资源
响应式编程
SaaS
函数计算

发表于 | 更新于 | 分类于

简介

DevOps由开发(developments)和运维(operations)两个单词组成。DevOps鼓励不同的开发部门共同协作。

DevOps起源于一名软件开发工程师Patrick Debios，他对于开发和运维之间的对立感到相当不爽。

DevOps,想要强调个体和互动是非常重要的，并且这个技术很可能有助于拆除企业里的部门墙。

开发团队、测试团队和运维团队会使用不同的系统来处理任务和缺陷。但是，三个系统都是相似的工作流程。三个系统变成一个系统存在可能，只需要为不同的角色展示不同的界面即可，这样会带来减少维护成本的长期利益。

DevOps的另一个核心目标是自动化和持续交付。

快速

DevOps化的转变必须要快。在高层次上，我们需要考虑抢占市场，在低层次上，我们需要紧盯任务。

DevOps工程师致力于让公司的流程更快、更有效，而且更可靠。只要有可能，就取代那些容易出错的重复性人力劳动。例如，如果你在程序编译时需要看机器人打气球，那么你的编译时间太长了。

增加企业内部各角色的交流就有很明显的价值。你的产品负责人可能想了解开发的进度并渴望能够先睹为快。像产品负责人这样的利益相关者，还有质量保证团队，都能够在测试环境跟上开发的节奏。

持续交付

开发人员

预打包开发环境，减少花费大量时间来创建开发环境。

版本控制系统

你需要决定文件夹结构的约定和使用的分支策略。

构建服务器

工件库

将构建好的二进制工件存放在一个库里。例如Nexus。

包管理器

在Red Hat系统上，这个命令是yum，或者是更新的dnf。Debian系的系统上市aptitude/dpkg。

测试环境

测试环境应该尽可能像生产环境。应该能使用和生产环境相同的方法进行安装和配置。

预发布/生产

预发布环境应该可以和生产环境互换。

发布管理

一个梦寐以求的场景是自动化的发布过程。但是这个很难实现的，需要有相当高程度的自动化测试，才有信心时间自动化部署。而这通常很难做到。另一个原因是业务业务和技术开发的节奏不一定相同。