创建型模式 第一，它们都将系统使用哪些具体类的信息封装起来；第二，它们隐藏了这些类的实例是如何被创建和组织的。
单例模式。
场景。只能有一个实例时的解决方法
抽象工厂模式。
场景。需要创建一系列对象的情况，同时，需求改动时，可能需要创建更多对象。如数据库变动，就需要改所有创建包含查询语句的对象。
解决方法。提供个接口，这接口可创建一系列相关或相互依赖的对象，客户端不用管是接口的实现类使用哪个数据库。OOP的精华：面向接口编程
建造者模式。
场景。整体由部分按一定方式构成，部分变化会影响构成整体的原方式。如盖楼的步骤一样，各部分材料不同，材料的变化，不会改变盖楼的步骤。
解决方法。把构建整体的方式，与每部分分离开，每部分的变化，不影响构成方式的变化。
简单工厂模式，十分常用。
场景。一个类的创建代码，如果分散在调用的位置，就会有很多相同的创建代码，修改创建代码，需要改很多处；同时，如果多个相似的子类的创建代码，分散在很多位置，加剧了上述相同；另外，采用子类而不是方法代表不同，方便了扩展，扩展时只需添加子类即可，不用为了加方法而改原类。
解决方法。容易变化的用类来实现，代替方法，类的上级可以是普通父类，也可以是接口或抽象类；用工厂类决定创建哪种子类，只需传入参数即可。带来问题是，如果变化太多，用于实现的类会很多，这时，最好使用原型模式，找到各实现类不用的局部点。
工厂模式
场景。用简单工厂模式时，加功能时，因创建实例的逻辑在工厂类里，需要改工厂类，违背了修改关闭原则。
解决办法。把简单工厂的内部逻辑，移到客户端代码，避免改工厂类。定义一个接口，
原型模式
场景。用简单工厂模式时，新的实现类只改变了一点，但还是要重写一个类，导致了大部分代码相同的实现类很多，改一处，需要改很多实现类。
解决办法。用memberwiseclone方法复制对象，并调用系统方法，实现深拷贝。不同处设值。