Estom的博客

载荷和载体循环定义一下这两者的概念，载荷试运行在载体上的内容信息，载体是运行载荷的工具。载荷和载体是相对的，例如当你在开发一个支付系统时。订单就是载荷，系统就是载体；但是相对于中间件/运维平台来说，支付系统就是载荷，中间件运维平台就是载体；相对于应用管理平台和容器服务平台来说，中间件平台又是载荷，容器服务平台又是载荷；依次类推容器服务是物理机的载体，物理机是容器服务的载荷；商品交易信息是订单的载荷，订单是商品交易信息的载体… … 载体是为载荷服务的。无论你处在哪一个位置，你开发的技术都是你服务对象的载体，你也是你一依赖的服务的载荷。所以开发者最主要的事情就是用好载体，服务载荷。

面向需求编程无论是设计阶段还是编码节点，都要遵循一定的逻辑，先做什么后做什么。 在设计阶段，首先要明确具体的需求是什么。功能需求和非功能需求。然后才可以进行概要设计和细节设计。 在编码阶段，最上层接口根据设计文档定义。在实现过程中，相当于撰写下层接口的需求说明，期望下层接口返回什么内容，可以提供给下层接口哪些值。然后再去定义下层接口。这样往复循环就可以完成分层设计中的每一层。前提是需要提前设计好每一层、每一个模块的功能边界。 一种方法是遵循自顶向下的设计和自底向上的实现，但这种方法需要在写设计文档的时候就明确每个模块之间的交互。这是一种标准的设计和实现方法。 但现实是，一些内容只有在编写的时候才会知道每个类之间的交互是怎样的，有哪些方法需要抽象出新的类，类中每个方法的入口和返回值是什么。 所以可以遵循自顶向下的设计实现。即首先编写最上册的设计，然后进行实现，实现过程中对下层接口的需求就是对下层接口的需求。

Creational Patterns（创建型模式）1 概述目标创建型模式（Creational Patterns）抽象了对象实例化过程。 用于 创建、组合和表示 一个系统的所有对象。 一个类创建型模式使用继承改变被实例化的类。 一个对象创建型模式将实例化委托给另一个对象。 随着系统演化得越来越依赖于对象复合而不是类的继承，创建型模式变得更为重要。 在这些模式中，有两个不断出现的主旋律： 它们都将关于该系统使用那些具体的类的信息封装起来。 它们隐藏了这些类的实例是如何被创建和放在一起的。 因此，创建型模式在什么被创建，谁创建它，它是怎样被创建的，以及何时创建这些方面给予你很大的灵活性。 Consequently, the creational patterns give you a lot of flexibility in what gets created, who creates it, how it gets created, and when. 2 具体方法Factory Method （工厂方法） Define an interface for creat...

单例模式Singleton1 概念意图保证一个类仅有一个实例，并提供一个访问它的全局访问点。 结构使用一个私有构造函数、一个私有静态变量以及一个公有静态函数来实现。 私有构造函数保证了不能通过构造函数来创建对象实例，只能通过公有静态函数返回唯一的私有静态变量。 参与者Singleton 定义一个 Instance 操作，允许客户访问它的唯一实例。Instance 是一个类操作。 可能负责创建它自己的唯一实例。 适用性在以下情况下可以使用 Singleton 模式： 当类只能有一个实例并且客户可以从一个众所周知的访问点访问它时。 当这个唯一实例应该是通过子类化可扩展的，并且客户应该无需更改代码就能使用一个扩展的实例时。 缺点 系统检查开销。实现中可能每次都需要检查实例是否存在，这个问题可以通过 Static 实例来解决。 系统资源开销。通常 Singleton 中的对象一旦被创建，不会被及时销毁。可以通过提供 Reset 操作来重置。 引起开发混淆。如果类包括 public 构造函数可以在外部构造，当使用 Singleton 对象时，开发人员需要记住不能使用...

简单工厂（Simple Factory）Intent在创建一个对象时不向客户暴露内部细节，并提供一个创建对象的通用接口。 Class Diagram简单工厂把实例化的操作单独放到一个类中，这个类就成为简单工厂类，让简单工厂类来决定应该用哪个具体子类来实例化。 这样做能把客户类和具体子类的实现解耦，客户类不再需要知道有哪些子类以及应当实例化哪个子类。客户类往往有多个，如果不使用简单工厂，那么所有的客户类都要知道所有子类的细节。而且一旦子类发生改变，例如增加子类，那么所有的客户类都要进行修改。 Implementation12public interface Product {} 12public class ConcreteProduct implements Product {} 12public class ConcreteProduct1 implements Product {} 12public class ConcreteProduct2 implements Product {} ...

工厂方法别名 虚构造器 （Virtual Constructor） 意图 定义一个用于创建目标对象的接口，让子类决定实例化哪一个目标类。Factory Method 使一个类的实例化延迟到其子类。 Define an interface for creating an object, but let subclasses decide which class to instantiate.Factory Method lets a class defer instantiation to subclasses. 结构 参与者 Product 定义工厂方法所创建的对象的接口（Interface）。 ConcreteProduct 实现 Product 接口。 Creator 声明工厂方法，该方法返回一个 Product 类型的对象。 Creator也可以定义一个工厂方法的缺省实现，它返回一个缺省的 ConcreteProduct 对象。 可以调用工厂方法以创建一个 Product 对象。 ConcreteCreator 重定义（Override）工厂方法以创...

抽象工厂abstract factory1 概念别名 Kit 意图提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。 结构抽象工厂模式创建的是对象家族，也就是很多对象而不是一个对象，并且这些对象是相关的，也就是说必须一起创建出来。而工厂方法模式只是用于创建一个对象，这和抽象工厂模式有很大不同。 抽象工厂模式用到了工厂方法模式来创建单一对象，AbstractFactory 中的 createProductA() 和 createProductB() 方法都是让子类来实现，这两个方法单独来看就是在创建一个对象，这符合工厂方法模式的定义。 至于创建对象的家族这一概念是在 Client 体现，Client 要通过 AbstractFactory 同时调用两个方法来创建出两个对象，在这里这两个对象就有很大的相关性，Client 需要同时创建出这两个对象。 从高层次来看，抽象工厂使用了组合，即 Cilent 组合了 AbstractFactory，而工厂方法模式使用了继承。 参与者AbstractFactory 声明一个创建抽象产品对象的操作接口。 Concrete...

生成器意图 将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。 结构 参与者 Builder 为创建一个 Product 对象的各个部件指定抽象接口。 ConcreteBuilder 实现 Builder 的接口以构造和装配该产品的各个部件。 定义并明确它所创建的表示。 提供一个检索产品的接口。 Director 构造一个使用 Builder 接口的对象。 Product 表示被构造的复杂对象。ConcreteBuilder创建该产品的内部表示并定义它的装配过程。 包含定义组成部件的类，包括将这些部件装配成最终产品的接口。 适用性 在以下情况下可以使用 Builder 模式： 当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时。 当构造过程必须允许被构造的对象有不同的表示时。 效果 它使你可以改变一个产品的内部表示。在改变该产品的内部表示时所要做的只是定义一个新的ConcreteBuilder。 它将构造代码和表示代码分开，提高了对象的模块性。客户不需要知道定义产品内部结构的类的所有信息。 它使你可...

原型模式别名 Clone 意图 用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。 Specify the kinds of objects to create using a prototypical instance, and createnew objects by copying this prototype. 结构 参与者 Prototype 声明一个克隆自身的接口。 ConcretePrototype 实现一个克隆自身的操作。 Client 让一个原型克隆自身从而创建一个新的对象。 适用性 在以下情况下可以使用 Prototype 模式： 一个系统要独立于它的产品的创建、构成和表示时。 当要实例化的类是在运行时刻指定时，例如：通过动态装载。 为了避免创建一个与产品类层次平行的工厂类层次时。 当一个类的实例只能有几个不同状态组合中的一种时。建立相应数目的原型并克隆它们可能比每次用合适的状态手工实例化该类更方便一些。 缺点 每一个 Prototype 子类都必须实现 Clone操作。当内部包括一些不支持拷贝或有循环引用的对象时...

Structural Patterns（结构型模式）1 概述目标结构型模式涉及到如何组合类和对象以获得更大的结构。 结构型类模式采用继承机制来组合接口实现。 结构型对象模式不是对接口和实现进行组合，而是描述了如何对一些对象进行组合，从而实现新功能的一些方法。 因为可以在运行时改变对象组合关系，所以对象组合方式具有更大的灵活性，而这种机制用静态组合是不可能实现的。 Adapter（适配器） 将一个类的接口转换成客户希望的另外一个接口。 Adapter 模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。 Bridge（桥接） 将抽象部分与它的实现部分分离，使它们都可以独立地变化。 Composite（组合） 将对象组合成树形结构以表示 “部分-整体” 的层次结构。 Composite 使得用户对于单个对象和组合对象的使用具有一致性。 Decorator（装饰） 动态地给一个对象添加一些额外的职责。 就增加功能来说，Decorator 模式相比生成子类更为灵活。 Facade（外观） 为子系统中的一组接口提供一个一致的界面。 Facade 模式定义了一个高...