但是，这种方式有一个问题，那就是如果** Intel 家产的 CPU 和 AMD 产的主板不能兼容使用**，那么这代码就容易出错，因为客户端并不知道它们不兼容，也就会错误地出现随意组合。
-下面就是我们要说的产品族的概念，它代表了组成某个产品的一系列附件的集合：
当涉及到这种产品族的问题的时候，就需要抽象工厂模式来支持了。我们不再定义 CPU 工厂、主板工厂、硬盘工厂、显示屏工厂等等，我们直接定义电脑工厂，每个电脑工厂负责生产所有的设备，这样能保证肯定不存在兼容问题。
这个时候，对于客户端来说，不再需要单独挑选 CPU厂商、主板厂商、硬盘厂商等，直接选择一家品牌工厂，品牌工厂会负责生产所有的东西，而且能保证肯定是兼容可用的。
public static void main(String[] args) { // 第一步就要选定一个“大厂” ComputerFactory cf = new AmdFactory(); // 从这个大厂造 CPU CPU cpu = cf.makeCPU(); // 从这个大厂造主板 MainBoard board = cf.makeMainBoard(); // 从这个大厂造硬盘 HardDisk hardDisk = cf.makeHardDisk(); // 将同一个厂子出来的 CPU、主板、硬盘组装在一起 Computer result = new Computer(cpu, board, hardDisk); }当然，抽象工厂的问题也是显而易见的，比如我们要加个显示器，就需要修改所有的工厂，给所有的工厂都加上制造显示器的方法。这有点违反了对修改关闭，对扩展开放这个设计原则。
单例模式单例模式用得最多，错得最多。
饿汉模式最简单：
public class Singleton { // 首先，将 new Singleton() 堵死 private Singleton() {}; // 创建私有静态实例，意味着这个类第一次使用的时候就会进行创建 private static Singleton instance = new Singleton(); public static Singleton getInstance() { return instance; } // 瞎写一个静态方法。这里想说的是，如果我们只是要调用 Singleton.getDate(...)， // 本来是不想要生成 Singleton 实例的，不过没办法，已经生成了 public static Date getDate(String mode) {return new Date();} }很多人都能说出饿汉模式的缺点，可是我觉得生产过程中，很少碰到这种情况：你定义了一个单例的类，不需要其实例，可是你却把一个或几个你会用到的静态方法塞到这个类中。
饱汉模式最容易出错：
public class Singleton { // 首先，也是先堵死 new Singleton() 这条路 private Singleton() {} // 和饿汉模式相比，这边不需要先实例化出来，注意这里的 volatile，它是必须的 private static volatile Singleton instance = null; public static Singleton getInstance() { if (instance == null) { // 加锁 synchronized (Singleton.class) { // 这一次判断也是必须的，不然会有并发问题 if (instance == null) { instance = new Singleton(); } } } return instance; } }双重检查，指的是两次检查 instance 是否为 null。
volatile 在这里是需要的，希望能引起读者的关注。
很多人不知道怎么写，直接就在 getInstance() 方法签名上加上 synchronized，这就不多说了，性能太差。
嵌套类最经典，以后大家就用它吧：
public class Singleton3 { private Singleton3() {} // 主要是使用了 嵌套类可以访问外部类的静态属性和静态方法 的特性 private static class Holder { private static Singleton3 instance = new Singleton3(); } public static Singleton3 getInstance() { return Holder.instance; } }注意，很多人都会把这个嵌套类说成是静态内部类，严格地说，内部类和嵌套类是不一样的，它们能访问的外部类权限也是不一样的。
最后，一定有人跳出来说用枚举实现单例，是的没错，枚举类很特殊，它在类加载的时候会初始化里面的所有的实例，而且 JVM 保证了它们不会再被实例化，所以它天生就是单例的。不说了，读者自己看着办吧，不建议使用。
建造者模式经常碰见的 XxxBuilder 的类，通常都是建造者模式的产物。建造者模式其实有很多的变种，但是对于客户端来说，我们的使用通常都是一个模式的
Food food = new FoodBuilder().a().b().c().build(); Food food = Food.builder().a().b().c().build();套路就是先 new 一个 Builder，然后可以链式地调用一堆方法，最后再调用一次 build() 方法，我们需要的对象就有了。
来一个中规中矩的建造者模式：
class User { // 下面是“一堆”的属性 private String name; private String password; private String nickName; private int age; // 构造方法私有化，不然客户端就会直接调用构造方法了 private User(String name, String password, String nickName, int age) { this.name = name; this.password = password; this.nickName = nickName; this.age = age; } // 静态方法，用于生成一个 Builder，这个不一定要有，不过写这个方法是一个很好的习惯， // 有些代码要求别人写 new User.UserBuilder().a()...build() 看上去就没那么好 public static UserBuilder builder() { return new UserBuilder(); } public static class UserBuilder { // 下面是和 User 一模一样的一堆属性 private String name; private String password; private String nickName; private int age; private UserBuilder() { } // 链式调用设置各个属性值，返回 this，即 UserBuilder public UserBuilder name(String name) { this.name = name; return this; } public UserBuilder password(String password) { this.password = password; return this; } public UserBuilder nickName(String nickName) { this.nickName = nickName; return this; } public UserBuilder age(int age) { this.age = age; return this; } // build() 方法负责将 UserBuilder 中设置好的属性“复制”到 User 中。 // 当然，可以在 “复制” 之前做点检验 public User build() { if (name == null || password == null) { throw new RuntimeException("用户名和密码必填"); } if (age <= 0 || age >= 150) { throw new RuntimeException("年龄不合法"); } // 还可以做赋予”默认值“的功能 if (nickName == null) { nickName = name; } return new User(name, password, nickName, age); } } }核心是：先把所有的属性都设置给 Builder，然后 build() 方法的时候，将这些属性复制给实际产生的对象。
看看客户端的调用：
public class APP { public static void main(String[] args) { User d = User.builder() .name("foo") .password("pAss12345") .age(25) .build(); } }