|
|
作为工程师，编码中一定会遇到以下问题：
- 如何分层、分模块？
- 如何划分类？类之间如何交互？
- 用继承还是组合？用接口还是抽象类？
- 怎样做到解耦、高内聚低耦合？
- 该用单例模式还是静态方法？
这些都是非常具体，非常常见的问题吧？
想要理解透设计模式的思想和原则，光看理论基本没用，结合源码阅读，才能事半功倍。
工厂模式
工厂模式（Factory Pattern）最常用的设计模式之一。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。
在工厂模式中，我们在创建对象时不会对客户端暴露创建逻辑，并且是通过使用一个共同的接口来指向新创建的对象。
意图： 定义一个创建对象的接口，让其子类自己决定实例化哪一个工厂类，工厂模式使其创建过程延迟到子类进行。
主要解决： 主要解决接口选择的问题。
何时使用： 我们明确地计划不同条件下创建不同实例时。
如何解决： 让其子类实现工厂接口，返回的也是一个抽象的产品。
关键代码： 创建过程在其子类执行。
应用实例：
1. 您需要一辆汽车，可以直接从工厂里面提货，而不用去管这辆汽车是怎么做出来的，以及这个汽车里面的具体实现。
2. Hibernate 换数据库只需换方言和驱动就可以。
优点：
1. 一个调用者想创建一个对象，只要知道其名称就可以了。
2. 扩展性高，如果想增加一个产品，只要扩展一个工厂类就可以。
3. 屏蔽产品的具体实现，调用者只关心产品的接口。
缺点： 每次增加一个产品时，都需要增加一个具体类和对象实现工厂，使得系统中类的个数成倍增加，在一定程度上增加了系统的复杂度，同时也增加了系统具体类的依赖。这并不是什么好事。
使用场景：
1. 日志记录器：记录可能记录到本地硬盘、系统事件、远程服务器等，用户可以选择记录日志到什么地方。
2. 数据库访问，当用户不知道最后系统采用哪一类数据库，以及数据库可能有变化时。
3. 设计一个连接服务器的框架，需要三个协议，"POP3"、"IMAP"、"HTTP"，可以把这三个作为产品类，共同实现一个接口。
注意事项： 作为一种创建类模式，在任何需要生成复杂对象的地方，都可以使用工厂方法模式。有一点需要注意的地方就是复杂对象适合使用工厂模式，而简单对象，特别是只需要通过 new 就可以完成创建的对象，无需使用工厂模式。如果使用工厂模式，就需要引入一个工厂类，会增加系统的复杂度。
抽象工厂模式
抽象工厂模式（Abstract Factory Pattern）是围绕一个超级工厂创建其他工厂。该超级工厂又称为其他工厂的工厂。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。
在抽象工厂模式中，接口是负责创建一个相关对象的工厂，不需要显式指定它们的类。每个生成的工厂都能按照工厂模式提供对象。
意图： 提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
主要解决： 主要解决接口选择的问题。
何时使用： 系统的产品有多于一个的产品族，而系统只消费其中某一族的产品。
如何解决： 在一个产品族里面，定义多个产品。
关键代码： 在一个工厂里聚合多个同类产品。
应用实例： 工作了，为了参加一些聚会，肯定有两套或多套衣服吧，比如说有商务装（成套，一系列具体产品）、时尚装（成套，一系列具体产品），甚至对于一个家庭来说，可能有商务女装、商务男装、时尚女装、时尚男装，这些也都是成套的，即一系列具体产品。假设一种情况（现实中是不存在的，要不然，没法进入共产主义了，但有利于说明抽象工厂模式），在您的家中，某一个衣柜（具体工厂）只能存放某一种这样的衣服（成套，一系列具体产品），每次拿这种成套的衣服时也自然要从这个衣柜中取出了。用 OO 的思想去理解，所有的衣柜（具体工厂）都是衣柜类的（抽象工厂）某一个，而每一件成套的衣服又包括具体的上衣（某一具体产品），裤子（某一具体产品），这些具体的上衣其实也都是上衣（抽象产品），具体的裤子也都是裤子（另一个抽象产品）。
优点： 当一个产品族中的多个对象被设计成一起工作时，它能保证客户端始终只使用同一个产品族中的对象。
缺点： 产品族扩展非常困难，要增加一个系列的某一产品，既要在抽象的 Creator 里加代码，又要在具体的里面加代码。
使用场景：
1. QQ 换皮肤，一整套一起换。
2. 生成不同操作系统的程序。
注意事项： 产品族难扩展，产品等级易扩展。
单例模式
单例模式（Singleton Pattern）是 Java 中最简单的设计模式之一。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。
这种模式涉及到一个单一的类，该类负责创建自己的对象，同时确保只有单个对象被创建。这个类提供了一种访问其唯一的对象的方式，可以直接访问，不需要实例化该类的对象。
注意：
· 1、单例类只能有一个实例。
· 2、单例类必须自己创建自己的唯一实例。
· 3、单例类必须给所有其他对象提供这一实例。
意图： 保证一个类仅有一个实例，并提供一个访问它的全局访问点。
主要解决： 一个全局使用的类频繁地创建与销毁。
何时使用： 当您想控制实例数目，节省系统资源的时候。
如何解决： 判断系统是否已经有这个单例，如果有则返回，如果没有则创建。
关键代码： 构造函数是私有的。
应用实例：
1. 一个班级只有一个班主任。
2. Windows 是多进程多线程的，在操作一个文件的时候，就不可避免地出现多个进程或线程同时操作一个文件的现象，所以所有文件的处理必须通过唯一的实例来进行。
3. 一些设备管理器常常设计为单例模式，比如一个电脑有两台打印机，在输出的时候就要处理不能两台打印机打印同一个文件。
优点：
1. 在内存里只有一个实例，减少了内存的开销，尤其是频繁的创建和销毁实例（比如管理学院首页页面缓存）。
2. 避免对资源的多重占用（比如写文件操作）。
缺点： 没有接口，不能继承，与单一职责原则冲突，一个类应该只关心内部逻辑，而不关心外面怎么样来实例化。
使用场景：
1. 要求生产唯一序列号。
2. WEB 中的计数器，不用每次刷新都在数据库里加一次，用单例先缓存起来。
3. 创建的一个对象需要消耗的资源过多，比如 I/O 与数据库的连接等。
**注意事项：**getInstance() 方法中需要使用同步锁 synchronized (Singleton.class) 防止多线程同时进入造成 instance 被多次实例化。
建造者模式
建造者模式（Builder Pattern）使用多个简单的对象一步一步构建成一个复杂的对象。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。
一个 Builder 类会一步一步构造最终的对象。该 Builder 类是独立于其他对象的。
意图： 将一个复杂的构建与其表示相分离，使得同样的构建过程可以创建不同的表示。
主要解决： 主要解决在软件系统中，有时候面临着 "一个复杂对象" 的创建工作，其通常由各个部分的子对象用一定的算法构成；由于需求的变化，这个复杂对象的各个部分经常面临着剧烈的变化，但是将它们组合在一起的算法却相对稳定。
何时使用： 一些基本部件不会变，而其组合经常变化的时候。
如何解决： 将变与不变分离开。
关键代码： 建造者：创建和提供实例，导演：管理建造出来的实例的依赖关系。
应用实例：
1. 去肯德基，汉堡、可乐、薯条、炸鸡翅等是不变的，而其组合是经常变化的，生成出所谓的 "套餐"。
2. JAVA 中的 StringBuilder。
优点：
1. 建造者独立，易扩展。
2. 便于控制细节风险。
缺点：
1. 产品必须有共同点，范围有限制。
2. 如内部变化复杂，会有很多的建造类。
使用场景：
1. 需要生成的对象具有复杂的内部结构。
2. 需要生成的对象内部属性本身相互依赖。
注意事项： 与工厂模式的区别是：建造者模式更加关注与零件装配的顺序。
由于篇幅限制，小编这里暂时只分享以上三种模式，完整版的45种设计模式于六大原则小编已经整理成了一份pdf文档了，方便大家查阅，那么要如何获取到这分资料呢？可以关注一下小编，后台私信：设计模式，即可获取文档资料。
建造者模式
原型模式
对象池模式
多例模式
静态工厂模式
桥接模式
关注一下小编，后台私信：设计模式，即可获取文档资料。 |
|
发表于 2021-2-17 21:21:43
