企业开发进阶-5-DockerQuickStart
Docker 简介Docker官网
Docker官方文档
Docker源码
概述Docker 是一个开源的应用容器引擎，基于 Go 语言 并遵从 Apache2.0 协议开源。
Docker 可以让开发者打包他们的应用以及依赖包到一个轻量级、可移植的容器中，然后发布到任何流行的 Linux 机器上，也可以实现虚拟化。
容器是完全使用沙箱机制，相互之间不会有任何接口（类似 iPhone 的 app），更重要的是容器性能开销极低。
应用场景
Web 应用的自动化打包和发布。
自动化测试和持续集成、发布。
在服务型环境中部署和调整数据库或其他的后台应用。
从头编译或者扩展现有的 OpenShift 或 Cloud Foundry 平台来搭建自己的 PaaS 环境。
优点Docker 是一个用于开发，交付和运行应用程序的开放平台。Docker 使您能够将应用程序与基础架构分开，从而可以快速交付软件。借助 Docker，您可以与管理应用程序相同的方式来管理基础架构。通过利用 Docker 的方法来快速交付，测试和部署代码，您可以大大减少编写代码和在生产环境中运行代码之间的延迟。
1、快速， ...
设计模式-14-访问者模式
访问者模式
在访问者模式中，使用了一个访问者类，它改变了元素类的执行算法。
通过这种方式，元素的执行算法可以随着访问者改变而改变。
属于行为型模式。根据模式，元素对象已接受访问者对象，这样访问者对象就可以处理元素对象上的操作。
意图：
主要将数据结构与数据操作分离。
主要解决：
稳定的数据结构和易变的操作耦合问题。
何时使用：
需要对一个对象结构中的对象进行很多不同的并且不相关的操作，而需要避免让这些操作”污染”这些对象的类，使用访问者模式将这些封装到类中。
如何解决：
在被访问的类里面加一个对外提供接待访问者的接口。
关键代码：
在数据基础类里面有一个方法接受访问者，将自身引用传入访问者。
优点：
符合单一职责原则
优秀的扩展性
灵活性。
缺点：
具体元素对访问者公布细节，违反了迪米特原则
具体元素变更比较困难
违反了依赖倒置原则，依赖了具体类，没有依赖抽象。
使用场景：
对象结构中对象对应的类很少改变，但经常需要在此对象结构上定义新的操作
需要对一个对象结构中的对象进行很多不同的并且不相关的操作，而需要避免让这些操作”污染”这些对象的类，也不希望在增加新操作时 ...
设计模式-13-命令模式
命令模式
命令模式是一种数据驱动的设计模式，它属于行为型模式。
请求以命令的形式包裹在对象中，并传给调用对象。调用对象寻找可以处理该命令的合适的对象，并把该命令传给相应的对象，该对象执行命令。
意图：
将一个请求封装成一个对象，从而使您可以用不同的请求对客户进行参数化。
主要解决：
在软件系统中，行为请求者与行为实现者通常是一种紧耦合的关系，但某些场合，比如需要对行为进行记录、撤销或重做、事务等处理时，这种无法抵御变化的紧耦合的设计就不太合适。
何时使用：
在某些场合，比如要对行为进行”记录、撤销/重做、事务”等处理，这种无法抵御变化的紧耦合是不合适的。在这种情况下，如何将”行为请求者”与”行为实现者”解耦？将一组行为抽象为对象，可以实现二者之间的松耦合。
如何解决：
通过调用者调用接受者执行命令，顺序：调用者→命令→接受者。
关键代码：
定义三个角色：1、received 真正的命令执行对象 2、Command 3、invoker 使用命令对象的入口
优点：
降低了系统耦合度
新的命令可以很容易添加到系统中去。
缺点：
使用命令模式可能会导致某些系统有过多的具体命令类。
注 ...
设计模式-12-模板模式
模板模式
在模板模式中，一个抽象类公开定义了执行它的方法的方式/模板。
它的子类可以按需要重写方法实现，但调用将以抽象类中定义的方式进行。
属于行为型模式。
意图：
定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
主要解决：
一些方法通用，却在每一个子类都重新写了这一方法。
何时使用：
有一些通用的方法。
如何解决：
将这些通用算法抽象出来。
关键代码：
在抽象类实现，其他步骤在子类实现。
优点：
封装不变部分，扩展可变部分
提取公共代码，便于维护
行为由父类控制，子类实现。
缺点：
每一个不同的实现都需要一个子类来实现，导致类的个数增加，使得系统更加庞大。
使用场景：
有多个子类共有的方法，且逻辑相同
重要的、复杂的方法，可以考虑作为模板方法。
注意事项：
为防止恶意操作，一般模板方法都加上 final 关键词。
案例说明将创建一个定义操作的 Game 抽象类，其中，模板方法设置为 final，这样它就不会被重写。Cricket 和 Football 是扩展了 Game 的实体类，它们重写了 ...
设计模式-11-代理模式
代理模式代理模式：为一个对象提供一个替身，以控制对这个对象的访问。即通过代理对象访问目标对象。在代理模式（Proxy Pattern）中，一个类代表另一个类的功能。这种类型的设计模式属于结构型模式。
可以在目标对象实现的基础上扩展目标对象的功能。
被代理的对象可以是远程对象、创建开销大的对象或需要安全控制的对象
代理模式有不同的形式，主要有三种 静态代理、动态代理 (JDK 代理、接口代理)和Cglib 代理(可以在内存动态的创建对象，而不需要实现接口， 他是属于动态代理的范畴) 。
意图：
为其他对象提供一种代理以控制对这个对象的访问。
何时使用：
想在访问一个类时做一些控制。
如何解决：
增加中间层。
关键代码：
实现与被代理类组合。
优点：
职责清晰
高扩展性
智能化。
缺点：
由于在客户端和真实主题之间增加了代理对象，因此有些类型的代理模式可能会造成请求的处理速度变慢
实现代理模式需要额外的工作，有些代理模式的实现非常复杂。
注意事项：
和适配器模式的区别：适配器模式主要改变所考虑对象的接口，而代理模式不能改变所代理类的接口
和装饰器模式的区别：装 ...
设计模式-10-享元模式
享元模式
享元模式主要用于减少创建对象的数量，以减少内存占用和提高性能
属于结构型模式，它提供了减少对象数量从而改善应用所需的对象结构的方式。
享元模式尝试重用现有的同类对象，如果未找到匹配的对象，则创建新对象
意图：
运用共享技术有效地支持大量细粒度的对象。
主要解决：
在有大量对象时，有可能会造成内存溢出，我们把其中共同的部分抽象出来，如果有相同的业务请求，直接返回在内存中已有的对象，避免重新创建。
何时使用：
系统中有大量对象
这些对象消耗大量内存
这些对象的状态大部分可以外部化
这些对象可以按照内蕴状态分为很多组，当把外蕴对象从对象中剔除出来时，每一组对象都可以用一个对象来代替
系统不依赖于这些对象身份，这些对象是不可分辨的。
如何解决：
用唯一标识码判断，如果在内存中有，则返回这个唯一标识码所标识的对象。
关键代码：
用 HashMap 存储这些对象。
应用实例：
JAVA 中的 String，如果有则返回，如果没有则创建一个字符串保存在字符串缓存池里面
数据库的连接池。
优点：
大大减少对象的创建，降低系统的内存，使效率提高。
缺点：
提高了系统的复杂度，需 ...
