1. 介绍

Docker 使用 Google 公司推出的 Go 语言 进行开发实现，基于 Linux 内核的 cgroup，namespace，以及 AUFS 类的 Union FS 等技术，对进程进行封装隔离，属于 操作系统层面的虚拟化技术。由于隔离的进程独立于宿主和其它的隔离的进程，因此也称其为容器。

2. 基本概念

• 镜像（Image）
• 容器（Container）
• 仓库（Repository）

1.设置类库程序集自动更新版本号

修改AssemblyInfo文件

• 更改[assembly: AssemblyVersion(“1.0.*”)]
• 注释[assembly: AssemblyFileVersion(“1.0.0”)]

1 键值对

• SET TESTKEY “TESTVALUE”,设置键值对TESTKEY-“TESTVALUE”，返回OK；
• GET TESTKEY,获取键TESTKEY的值（获取不存在的键的值返回nil，即空）；
• DEL TESTKEY,删除键为TESTKEY的键值对，成功返回1；
• EXISTS TESTKEY,键是否存在，0否1是
• TYPE TESTKEY,返回键的类型，如string、list等，若键不存在返回None;
• INCR TESTKEY,自动加一，成功返回结果（若TESTKEY不是int值，则报错）
  注意：INCR命令是原子操作（即不会被线程调度机制打断的操作）;
• SETNX TEST1 ‘TESTVALUE’，若键不存在则设置，若键存在则不设置，成功返回1，失败返回0；
• EXPIRE TESTKEY 120,设置键TESTKEY有效期120秒（等同于 SET TESTKEY ‘TESTVALUE’ EX 120）；
• PERSIST TESTKEY,取消TESTKEY的有效期，1成功0失败
• TTL TESTKEY,查看键TESTKEY剩余有效期,-2表示键已过期不存在，-1表示永不过期，若重下SET TESTKEY，则状态重置为-1;

1 意图

将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。

2 别名

无

3 动机

一个RTF（Rich Text Format）文档交换格式的阅读器应能将 RTF 转换为多种正文格式。该阅读器可以将 RTF 文档转换成普通 ASCII 文本或转换成一个能以交互方式编辑的正文窗口组件。但问题在于可能转换的数目是无限的。因此要能够很容易实现新的转换的增加，同时却不改变 RTF 阅读器。

1 意图

提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。

2 别名

Kit

3 动机

考虑一个支持多种视感（look - and - feel）标准的用户界面工具包，例如 Motif 和 Presentation Manager。不同的视感风格为诸如滚动条、窗口和按钮等用户界面“窗口组件”定义不同的外观和行为。为保证视感风格标准间的可移植性，一个应用不应该为一个特定的视感外观硬编码它的窗口组件。在整个应用中实例化特定视感风格的窗口组件类将使得以后很难改变视感风格。

1.针对接口编程，而不是针对实现编程。

2.优先使用对象组合，而不是类继承。

3.SOLID原则

• S（SRP，The Single Responsibility Principle，单一责任原则）：就一个类而言，应该只有一个引起它变化的原因。如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会影响到其他的职责，另外，把多个职责耦合在一起，也会影响复用性。
• O（OCP，Open-Closed Principle，开闭原则）：一个软件实体（指的类、函数、模块等）应该对扩展开放，对修改关闭。即每次发生变化时，要通过添加新的代码来增强现有类型的行为，而不是修改原有的代码。　　符合开闭原则的最好方式是提供一个固有的接口，然后让所有可能发生变化的类实现该接口，让固定的接口与相关对象进行交互。
• L（LSP，Liskov Substitution Principle，里氏代替原则）：指的是子类必须替换掉它们的父类型。也就是说，在软件开发过程中，子类替换父类后，程序的行为是一样的。只有当子类替换掉父类后，此时软件的功能不受影响时，父类才能真正地被复用，而子类也可以在父类的基础上添加新的行为。
• I（ISP，Interface Segregation Principle，接口隔离原则）：使用多个专门的接口比使用单一的总接口要好。也就是说不要让一个单一的接口承担过多的职责，而应把每个职责分离到多个专门的接口中，进行接口分离。过于臃肿的接口是对接口的一种污染。
• D（DIP，Dependence Inversion Principle，依赖倒置原则）： 高层模块不应该依赖于低层模块，二者都应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象，也就是提出的 “面向接口编程，而不是面向实现编程”。这样可以降低客户与具体实现的耦合。

4.合成复用原则（Composite Reuse Principle, CRP）

在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分。新对象通过向这些对象的委派达到复用已用功能的目的。简单地说，就是要尽量使用合成/聚合，尽量不要使用继承。

5.迪米特法则（Law of Demeter，LoD）又名最少知识原则（Least Knowledge Principle，LKP）

一个对象应当对其他对象有尽可能少的了解。也就是说，一个模块或对象应尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立，这样当一个模块修改时，影响的模块就会越少，扩展起来更加容易。关于迪米特法则其他的一些表述有：只与你直接的朋友们通信；不要跟“陌生人”说话。外观模式（Facade Pattern)和中介者模式（Mediator Pattern）就使用了迪米特法则。

1 总体介绍

1.1 什么是设计模式

四个基本要素：

1. 模式名称（pattern name） 一个助记名，它用一两个词来描述模式的问题、解决方案和效果。命名一个新的模式增加了我们的设计词汇。设计模式允许我们在较高的抽象层次上进行设计。基于一个模式词汇表，我们自己以及同事之间就可以讨论模式并在编写文档时使用它们。模式名可以帮助我们思考，便于我们与其他人交流设计思想及设计结果。找到恰当的模式名也是我们设计模式编目工作的难点之一。
2. 问题(problem) 描述了应该在何时使用模式。它解释了设计问题和问题存在的前因后果，它可能描述了特定的设计问题，如怎样用对象表示算法等。也可能描述了导致不灵活设计的类或对象结构。有时候，问题部分会包括使用模式必须满足的一系列先决条件。
3. 解决方案(solution) 描述了设计的组成成分，它们之间的相互关系及各自的职责和协作方式。因为模式就像一个模板，可应用于多种不同场合，所以解决方案并不描述一个特定而具体的设计或实现，而是提供设计问题的抽象描述和怎样用一个具有一般意义的元素组合（类或对象组合）来解决这个问题。
4. 效果(consequences) 描述了模式应用的效果及使用模式应权衡的问题。尽管我们描述设计决策时，并不总提到模式效果，但它们对于评价设计选择和理解使用模式的代价及好处具有重要意义。软件效果大多关注对时间和空间的衡量，它们也表述了语言和实现问题。因为复用是面向对象设计的要素之一，所以模式效果包括它对系统的灵活性、扩充性或可移植性的影响，显式地列出这些效果对理解和评价这些模式很有帮助。

1.介绍

ASP.NET Core 通过多环境控制 APP 的行为，例如 development，staging 和 production。环境变量决定了运行环境，从而根据不同环境采用不同配置。

1.什么是Markdown

Markdown是一种在web显示带样式风格文本的方式。你能通过它控制文本的字体样式、插入图片、插入列表等。通常，Markdown使用一些特殊的非字母符号来作为语法规则，如#等。你能在Github上大部分地方使用Markdown。比如：

• Gists
• Issues的评论、Pull Requests
• .md或.markdown后缀名的文件

1.初始化

git init

2.添加到仓库

git add $filename

3.提交到仓库

git commit -m “$comment”

4.查看状态

git status