uni-app 的 API 与微信小程序 API 基本一致。掌握微信小程序 API 对后面的开发很有帮助。微信小程序 API 文档:https://developers.weixin.qq.com/miniprogram/dev/api/

注册微信小程序账号，获取到 AppID，我们后面配置的时候会用到。在 HBuilderX 工具栏，点击发行，选择小程序-微信。输入小程序名称和 AppID，单击发行就可以了。这样我们就会获得一个微信小程序的打包文件，接下来我们来发布微信小程序项目，打开微信小程序开发者工具，导入刚刚生成的微信小程序项目的打包文件，在微信小程序开发者工具中先测试一下，项目运行是否正常，项目测试没有问题后，点击右上角>>按钮，上传代码就可以发布微信小程序了，最后等待微信团队审核通过，别人就可以在线上访问到你的项目了。

乐观是一种积极的解决问题的态度。所谓乐观锁认为系统中的事务并发更新不会很频繁，即使冲突了也没事，大不了重新再来一次。基本思想：每次提交一个事务更新时，查看要修改的数据从上次读取以后有没有被其它事务修改过，如果修改过，那么更新就会失败。实现方案：在实体中增加一个版本控制字段，每次事务更新后就将版本 (Version) 字段的值加 1。Tips： 乐观锁本质就是版本控制管理的实现，记录的每一次更新操作都会以版本递增的方式进行记录。一个事务在更新之前，先获取记录的当前版本号，更新时，如果版本还是最新的则可以更新，否则说明有事务比你先更新，则需要放弃。或者重新查询到最新版本信息后再更新。所以，在乐观锁的实现中，冲突是常态。实现过程：在学生实体类中添加新属性，用来记录每次更新的版本号。public class Student implements Serializable {//省略…… @Versionprivate Long version;//省略…… ｝stu = (Student) session.get(Student.class, new Integer(1));System.out.println("当前版本号："+stu.getVersion);//模拟延迟，如果在这个时间内有其它事务进行了更新操作，此事务的更新不会成功Thread.sleep(30000);stu.setStuName("Hibernate");transaction.commit();好了，悲观也好，乐观也好，只是一种解决问题的态度。对于这两种态度，咱们要总结一下。乐观锁：优势：性能好，并发性高。缺点：用户体验不好，可能会出现高高兴兴去更新，却告知已经有人捷足先登了。悲观锁：优势：锁住记录为我所用，没修改完成之前，其他事务只能瞪眼瞧着，时间虽然延迟，至少心里有底。缺点：并发性不好，性能不高。Hibernate 的其它性能优化：随时使用 Session.clear（）及时清除 Session 缓存区的内容；1+N 问题 ( 一条 SQL 语句能解决的问题用了很多条 SQL 语句来实现) ；使用 Criteria 查询可以解决这个问题；Lazy 加载：需要时，使用 get（） 方法发出 SQL 语句。使用类似于 from Student s left join s.classRoom c 的关联查询语句。缓存使用：在对象更新、删除、添加相对于查询要少得多时， 二级缓存的应用将不怕 n+1 问题，因为即使第一次查询很慢，之后直接缓存命中也是很快的，刚好又利用了 n+1。

定义：乐观锁是相对悲观锁来说的，它认为数据在一般情况下不会造成冲突，所以在访问记录前不会加排它锁，而是在进行数据提交更新的时候，才会正式对数据冲突与否进行检测。乐观锁的实现：依旧拿数据库的锁进行比较介绍，乐观锁并不会使用数据库提供的锁机制， 一般在表中添加 version 宇段或者使用业务状态来实现。 乐观锁直到提交时才锁定，所以不会产生任何死锁。Java 中的乐观锁：我们之前所学习的 CAS 原理即是乐观锁技术，当多个线程尝试使用 CAS 同时更新同一个变量时，只有其中一个线程能更新变量的值，而其它线程都失败，失败的线程并不会被挂起，而是被告知这次竞争中失败，并可以再次尝试。Tips：我们这里所说的对于乐观锁，当多个线程尝试使用 CAS 同时更新同一个变量时，只有其中一个线程能更新变量的值，而其它线程都失败。注意失败两字，失败意味着有操作，而悲观锁是等待，意味着不能同时操作。

可以看到，乐观锁虽然有缺陷，它会使更新失败，因此必须重复获取数据然后重试，但是它保证了数据的正确性和完整性。在读多写少的场景下，乐观锁不会出现太多的重试，当然如果出现了很多重试，证明场景已经可能不是读多写少了，可以尝试换方案了。乐观锁的实现也颇为简单，不需要任何第三方依赖，你完全可以自己直接实现，不过仍然有一些第三方框架提供了开箱即用的乐观锁，你可以根据自己的使用语言和生态去查找相应的乐观锁框架。

这是一种优化的读模式。乐观读模式相关的几个方法如下。tryOptimisticRead () 方法：非阻塞尝试乐观获取读锁，只有当写锁没有被获取时返回一个非 0 的 stamp 。乐观读取模式适用于短时间读取操作，降低竞争和提高吞吐量。在使用时一般需将数据存储到一个副本中，在后继处理中用于对比数据是否是最新状态；validate (long stamp) 方法：用于检查在获取到读锁 stamp 后，锁有没被其他写线程抢占。如果写锁没有被获取，那么 validate () 方法返回 true。可多次调用验证这一信息。另外，此类也提供了一组读写锁之间的转换方法：tryConvertToWriteLock (long stamp) 方法：尝试转换为写锁。转换条件：tryConvertToReadLock (long stamp) 方法：尝试转换为悲观读锁。tryConvertToOptimisticRead (long stamp) 方法：尝试转换为乐观读锁。注意此类的编程方法有这样一个共通特征：所有获取锁的方法，都返回一个邮戳（Stamp），Stamp 为 0 表示获取失败，其余都表示成功；所有释放锁的方法，都需要一个邮戳（Stamp），这个 Stamp 必须是和成功获取锁时得到的 Stamp 一致；下面我们举一个具体的编程例子。

乐观锁的使用十分广泛，我们也推荐你在实际的开发中使用乐观锁，接下来，我们以一个例子来详细的说明一下乐观锁。我们新建一个测试数据表 imooc_order ：DROP TABLE IF EXISTS imooc_order;CREATE TABLE imooc_order( id int PRIMARY KEY, price decimal(10,2), -- version 字段作为乐观锁版本控制位 version int NOT NULL DEFAULT 0);INSERT INTO imooc_order(id,price,version)VALUES (1,23.2,1);注意： 我们已经在表中添加了 version 字段

为了更好地理解悲观锁与乐观锁，我们通过设置一个简单的示例场景来进行分析。并且我们采用悲观锁 synchronized 和乐观锁 Atomic 操作进行分别实现。Atomic 操作类，指的是 java.util.concurrent.atomic 包下，一系列以 Atomic 开头的包装类。例如 AtomicBoolean，AtomicInteger，AtomicLong。它们分别用于 Boolean，Integer，Long 类型的原子性操作。Atomic 操作的底层实现正是利用的 CAS 机制，而 CAS 机制即乐观锁。场景设计：创建两个线程，创建方式可自选；定义一个全局共享的 static int 变量 count，初始值为 0；两个线程同时操作 count，每次操作 count 加 1；每个线程做 100 次 count 的增加操作。结果预期：最终 count 的值应该为 200。悲观锁 synchronized 实现：public class DemoTest extends Thread{ private static int count = 0; //定义count = 0 public static void main(String[] args) { for (int i = 0; i < 2; i++) { //通过for循环创建两个线程 new Thread(new Runnable() { @Override public void run() { try { Thread.sleep(10); } catch (Exception e) { e.printStackTrace(); } //每个线程让count自增100次 for (int i = 0; i < 100; i++) { synchronized (DemoTest.class){ count++; } } } }). start(); } try{ Thread.sleep(2000); }catch (Exception e){ e.printStackTrace(); } System.out.println(count); }}结果验证：200乐观锁 Atomic 操作实现：public class DemoTest extends Thread{ //Atomic 操作，引入AtomicInteger。这是实现乐观锁的关键所在。 private static AtomicInteger count = new AtomicInteger(0); public static void main(String[] args) { for (int i = 0; i < 2; i++) { new Thread(new Runnable() { @Override public void run() { try { Thread.sleep(10); } catch (Exception e) { e.printStackTrace(); } //每个线程让count自增100次 for (int i = 0; i < 100; i++) { count.incrementAndGet(); } } }). start(); } try{ Thread.sleep(2000); }catch (Exception e){ e.printStackTrace(); } System.out.println(count); }}结果验证：200代码解读：此处主要关注两个点，第一个是 count 的创建，是通过 AtomicInteger 进行的实例化，这是使用 Atomic 的操作的入口，也是使用 CAS 乐观锁的一个标志。第二个是需要关注 count 的增加 1 调用是 AtomicInteger 中 的 incrementAndGet 方法，该方法是原子性操作，遵循 CAS 原理。

Flask 是一个 Python 实现的 Web 开发微框架，但是这个“微”并不代表着 Flask 功能比较简陋、有所欠缺。微框架中的 “微” 意味着：Flask 旨在保持核心简单而易于扩展；Flask 不会替用户做出太多决策，比如使用何种数据库；Flask 的选项（比如使用何种模板引擎) 通常有多个，用户很容易替换。默认情况下，Flask 不包含数据库抽象层、模板引擎、身份认证或其它任何已有多种库可以胜任的功能，如下图所示。然而，Flask 支持用扩展来给应用添加这些功能，应用程序可以很方便的集成这些扩展。众多的扩展提供了数据库集成、表单验证、上传处理、各种各样的开放认证技术等功能。

在日常工作学习中，我们经常需要把有限的内容按照一定的比例进行分开，比如一天的时间用来工作，学习，娱乐，休息这样的时间需要进行按比例合理划分。一般这样多比较占比的时候大家一般都会使用饼图表示。饼图又称饼状图，用于描述量、频率或百分比之间的相对关系。

微前端 尚处在发展时期，其核心概念和 微服务 相似。现阶段较为常用的微前端框架为 single-spa 和 qiankun，后者是基于前者实现的。该技术能做到 技术栈无关，即一个应用，能由多个不同技术的子应用构成，同时做到子应用的相互隔离，这里的隔离就可以选择采用 Web Components 实现。

for…in 循环可以用来遍历对象的属性名。var obj = { name: '小红', age: 12, hobby: ['打篮球', '唱歌'],};for (key in obj) { console.log(obj[key]);}// 输出：// "小红"// 12// ["打篮球", "唱歌"]每一次遍历拿到的 key 就是对象的某一个属性名，当属性名被遍历完后会自动退出循环。有部分 key 是无法遍历到的，具体规则可以参阅对象章节。

1. 独立的页面维护了全局 错误码错误码由5位整数构成2. 每个接口一个独立的 参数说明页面正常情况下出参只返回业务实体异常情况才有 errCode errMsg每个接口下也可能有自己的业务错误码

咱们打开新浪微博，然后随便找个带皇冠的，按下F12键(Mac用户按command+option+i)然后选中控制台的箭头，再点击皇冠：再点开这个图片可以发现：可以看到那些大 V 图标皇冠图标以及各种微博认证等图标，都是放在了一张雪碧图里(即使再牛的大 V，身份标志也是放在雪碧图中的)。

乐观与悲观是两种不同的态度，从名字上看，二者就是以开发者的态度作为边界来分类的。乐观锁认为，同一数据在并发条件下，发生冲突是小概率事件，因此我们不加锁，而是加上版本号判断修改是否成功。悲观锁认为，同一数据在并发条件下，冲突是大概率事件，因此我们必须先加锁，不允许别人修改。悲观锁和乐观锁其实是一种思想，主要取决于开发者对待它的态度。在锁这一小节中，里面谈到的所有锁宏观上（可能实现的思想是乐观锁）来说都是悲观锁，因此一旦加锁，都会锁定数据，直到解锁才会释放。

上节课我们学习了基于 IEDA 搭建 Kotlin 的开发环境以及使用如何创建一个 Kotlin 项目。这节课我们继续学习在 Eclipse 下搭建 Kotlin 的开发环境。作为老牌的 Java 开发 IDE，使用 Eclipse 的开发者依然很多。在 Eclipse 下搭建 Kotlin 的开发环境要比 IDEA 稍微繁琐一些，下面我们一起来看一下。

不同的系统会有不同的默认 Button 样式，但是它们都有一个共同点——丑。相比于 TextView 而言，Button 是一个互动感很强的控件，除了设置字体字号，还需要有形状、背景、颜色、点击态等等样式变化。特别是在游戏及娱乐类 App 中 ，Button 的样式及变化效果将直接影响用户体验，所以这里将重点讲解几种设置样式的方法。

乐观锁不全依赖于数据库，一般情况下我们都是在代码层面上来完成它的，主流的设计思路是这样的：我们在数据表中添加一个字段version，version 代表版本号，字段类型为整型。当我们获取数据时，假设得到它的version字段为n，执行完其它操作对该数据进行更新时，会执行UPDATE ... SET version=n+1 WHERE version=n。如果在更新时，数据已经被别人更新过了，那么该数据的version字段已经不是n了，那么此时修改就会失败，反之修改就会成功。可以看到，乐观锁就像它的名称一样乐观，适合数据读多写少的场景，因为实际上并没锁住数据，所以性能十分可观；而悲观锁则与之相反，适合写多读少的场景，盲目的排他性一定程度上会大幅影响性能。

悲观锁：总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样其他线程想拿这个数据就会阻塞直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。乐观锁：总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号机制和 CAS 算法实现。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库提供的类似于 write_condition 机制，其实都是提供的乐观锁。

这里我们要给大家讲解一个好用的神奇的标签，就是 bgsound ，我们可以写一个这样的标签到网页的 body 标签里。 <bgsound src=""> 其中双引号中的部分，需要用你的本地音频文件目录位置进行替换。把这个标签粘贴到网页的 body 中，就可以为网页设置背景音乐了。由于是音频，所以老师就无法截图给大家说明了，大家只要按找老师说的方式去操作，就会很容易的给网页添加了背景音乐。

决策树其实很简单，我们日常生活中用到的例子非常多，举个简单的分类的例子：我中午饿了，要去吃饭，学校里面一共有两个餐厅，而我一共有4个选择：A餐厅：价格贵；B餐厅：价格便宜；吃泡面：不用出宿舍，前提是宿舍售卖机有卖；点外卖：不用出宿舍。那么，我们的决策树就如下图所示：如果我想出门而且有钱，我就去 A 餐厅；如果我想出门但是却钱不多，那么我就去 B 餐厅；倘若我不想出宿舍而刚刚好宿舍有卖泡面，我就可以直接吃泡面；到那时如果没有泡面的话，我就只能点外卖。这只是一个简单的理解，而具体的优化的细节涉及到许多的数学原理，这里就不过多解释了。

上一节我们介绍了「密码认证」的实现方法，本节我们讨论如何通过 OAuth2.0 方式直接从第三方机构获取用户身份信息的方法。OAuth（开放授权）是一个开放标准，允许用户授权第三方移动应用访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方移动应用或分享他们数据的所有内容，OAuth2.0 是 OAuth 协议的延续版本，但不向后兼容 OAuth1.0 即完全废止了 OAuth1.0。除了自建认证中心外，常用的互联网 OAuth2.0 认证中心还包括：QQ、微信、微博、Github 等，例如 imooc.com 的登录选项里，我们能看到「微博登录」、「微信登录」和「QQ 登录」，这些其实就是对 OAuth2.0 认证的应用。慕课网登录页面 /center>本节将以 Github 作为第三方认证中心为例，讨论如何使用 Spring security 实现 OAuth2 登录的功能。本节开发环境JDK 1.8Maven 3.5.3 依赖项：spring-security-config:5.3.2.RELEASEspring-security-oauth2-client:5.3.2.RELEASEspring-security-oauth2-jose:5.3.2.RELEASEspring-boot-starter-thymeleaf:2.3.0.RELEASEspring-boot-starter-web:2.3.0.RELEASEthymeleaf-extras-springsecurity5:3.0.4.RELEASE

ViewPager 是一种可以让用户通过左右滑动来切换页面的控件，通过它我们可以展示超过屏幕尺寸大小的内容，在某种程度上它可以说是实现多页面的最佳方式，同时 ViewPager 还支持任意动态的添加/删除页面。比如我们可以将不同的类别的内容分别放在不同页面当中，然后通过滑动切换不同的类别从而给用户展示不同的页面，这个在类似百度App等新闻类App中非常适用。在 ViewPager 中插入“娱乐”、“国际”、“体育”、“星座”等等新闻类别，然后在不同的 View 中展示不同的新闻内容，还可以根据用户的喜好动态增加/删除某些页面，接下来就一起来看看如何完成多页视图。

imooc_order表存放了订单信息（简略信息），而订单的价格并非一成不变的，它可能会同时被多个人改变。那么如何能够安全地修改它的价格，且不会跟别人冲突了。现在默认有两个人，甲现在拿到了id为1的订单，想要修改它的价格：SELECT * FROM imooc_order WHERE id = 1; 在甲拿到的同时，乙也同样拿到了订单数据，且订单此时的价格为23.2，版本号为1。甲决定修改订单的价格为33.3，于是他执行了如下语句：UPDATE imooc_order SET version = 1 + 1, price=33.3 WHERE id = 1 AND version = 1;甲执行成功了，而此时乙也需要修改价格，但是他并不知道价格已经修改：UPDATE imooc_order SET version = 1 + 1, price=22.1 WHERE id = 1 AND version = 1;很明显，乙修改失败了，因为在他修改价格之前，甲以微弱的速度优势已经修改了价格，且修改了 version字段，此时 version等于2。而乙提交 SQL 语句时，Where 中明确的写到 version 等于 1。即使乙修改失败，但是数据仍然是正确的，乙完全可以在失败的情况下重复获取一次数据再修改。如下图所示：

模板方法模式是定义一个操作中的算法的骨架，从而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。通常对于一些重要的复杂方法和多个子类共有的方法且逻辑相同的情况下会使用模板方法模式。比如用户第三方用户认证的时候就比较适合使用模板方法。我们来看一个例子：假设我们现在需要用到微信、微博的第三方用户授权来获取用户的信息。//使用模板方法模式描述获取第三方用户信息的过程 public abstract class Authentication{ public void checkUserAuthentication(){ checkIdentity(); fetchInfo(); } ​ protected abstract void checkIdentity(); protected abstract void fetchInfo(); } ​ //微信用户 public class WechatAuthenication extends Authentication{ @Override protected void checkIdentity() { System.out.println("获得微信用户授权"); } ​ @Override protected void fetchInfo() { System.out.println("获取微信用信息"); } } ​ //微信用户 public class WeiboAuthenication extends Authentication{ @Override protected void checkIdentity() { System.out.println("获得微博用户授权"); } ​ @Override protected void fetchInfo() { System.out.println("获取微博用信息"); } } ​ //调用模板方法 public class Demo{ public static void main(String...s){ Authentication auth = new WechatAuthenication(); auth.checkUserAuthentication(); auth = new WeiboAuthenication(); auth.checkUserAuthentication(); } }输出结果：获得微信用户授权 获取微信用信信息 获得微博用户授权 获取微博用信信息现在我们使用 Lambda 表达式换个角度来思考模板方法模式。如果我们用函数式接口来组织模板方法中的调用过程，相比使用继承来构建要显得灵活的多。//定义一个处理接口，用来处理一项事务，如授权或者获取信息。 public interface Processer{ public void process(); } ​ //封装调用过程 public class Authentication{ private final Processer identity; private final Processer userinfo; public Authentication(Criteria identity,Criteria userinfo){ this.identity = identity; this.userinfo = userinfo; } ​ public void checkUserAuthentication(){ identity.process(); userinfo.process(); } } ​ //使用模板方法 public class Demo{ Authentication auth = new Authentication(()->System.out.println("获得微信用户授权"), ()->System.out.println("获取微信用户信息")); auth.checkUserAuthentication(); auth = new Authentication(()->System.out.println("获得微博用户授权"), ()->System.out.println("获取微博用户信息")); auth.checkUserAuthentication(); }输出结果：获得微信用户授权 获取微信用信信息 获得微博用户授权 获取微博用信信息此时，我们的模板方法得到了大幅的简化，同时通过函数接口让模板方法获得了极大的灵活性。

我们希望操作系统能够同时处理多个任务，例如在播放网易云音乐的同时，也能在微信上聊天。计算机的核心处理硬件是 CPU，如果计算机只有一个 CPU，那么播放音乐和处理聊天软件都需要这个 CPU 去执行运算逻辑，那如何做到时间上的同时处理？答案是 CPU 在多个逻辑任务之间来回切换，因为切换速度太快，所以看起来做到了并发执行。传统操作系统的任务调度采用时间片轮转的方式，在执行一个任务达到时间限制时会暂停处理，然后切换到处理下一个任务。每一个任务执行的时间间隔就是一个时间片，被执行的任务处于运行状态，被暂停的任务处于就绪状态，如图所示：假设存在两个调度任务，CPU 调度产生并发的 "错觉"

#include <stdio.h>int main(){ int x = 9; // do { x--; printf("Number: %d\n", x); } while (x > 10); return 0;}运行结果：Number: 8这里的例子稍微特殊一点，可以更好的帮助大家理解这个语句。大家如果单独看循环条件的话是不满足的，因为变量 x 等于 9 ，这很明显不满足当 x 大于 10 才进行循环的条件。但是，这里我们还是执行了自减语句和屏幕输出语句， x 的值在执行自减语句后变为了 8 ，然后再向屏幕输出结果。

技巧 1如果我们的微服务监控平台没有任何数据，或者说，在打开微服务平台之后，各参数一直处于 loading 状态，这个时候，我们只需要在服务端调用任意一个服务接口即可，这样在微服务监控平台，我们就能看到被监控实例的参数了。技巧 2如果我们在访问 /actuator/hystrix.stream 路径时，系统找不到对应的路径，即报 404 异常，那么我们需要在对应项目的启动类中添加一个 Bean ：@Beanpublic ServletRegistrationBean hystrixMetricsStreamServlet() { ServletRegistrationBean registration = new ServletRegistrationBean(new HystrixMetricsStreamServlet()); registration.addUrlMappings("/hystrix.stream"); return registration;}这样我们就能正常访问 /actuator/hystrix.stream 下的路径了。

信息的搜集往往不是单一的，是由类似上面列举的很多方式的组合。我们经常听到一个词 人肉搜索，大家都很惊讶网络神人技术太强，其实主要还是因为我们散布在网上的资料信息太多了。这些零碎的资料拼一拼还是能获得很全的信息的。搜索引擎随便输入你的名字，或者外加几个关键词可能查到你在哪所学校，参加了某某活动，获得了某某名次的奖励你在哪所公司，缴交的一些社保信息你在某个网站的评论根据你的昵称到 QQ 上面搜索，同一个昵称到处用概率还是很大的，如果有手机号那就更加准确了，紧接着可以根据你的 QQ 空间获取更多你私人的信息。（这以前是非常好查的，现在腾讯也一直在完善信息安全这块）也可能是到其他平台去搜索：微博，头条，人人网，58同城 等照片网上搜索相似百度搜索引擎就有根据图片搜索到功能到政府的一些网站，如 信用xx ，上面根据法人名字也能搜索不少有价值的东西。

添加新需求时，如何做到不修改，去扩展？是不是想到了单一职责？是的，类的职责越单一，那么它就越稳定。RecommendMusicService 类的职责太多了，负责n种风格的推荐。OK，那么我们第一件事就是要减少 RecommendMusicService 类的职责，把每种不同风格的推荐提取到不同的类当中。比如MetalMusicRecommendService、PopMusicRecommendService、CountryMusicRecommendService。这些类都可以通过 recommed 方法生成推荐的歌曲清单。而 RecommendMusicService 类只是通过调用不同 MusicRecommendService 的 recommed 方法来实现推荐。代码如下：MetalMusicRecommendService 类：public class MetalMusicRecommendService { public List<String> recommend(){ List<String> recommendMusicList = new ArrayList<>(); recommendMusicList.add("Don't cry"); recommendMusicList.add("Fade to black"); return recommendMusicList; }}同类型的还有 GrungeMusicRecommendService、PopMusicRecommendService、CountryMusicRecommendService 类现在我们来改造 MusicRecommendService 类：public class RecommendMusicService { private MetalMusicRecommendService metalMusicRecommendService = new MetalMusicRecommendService(); private GrungeMusicRecommendService grungeMusicRecommendService = new GrungeMusicRecommendService(); private CountryMusicRecommendService countryMusicRecommendService = new CountryMusicRecommendService(); private PopMusicRecommendService popMusicRecommendService = new PopMusicRecommendService(); public List<String> recommend(String style) { List<String> recommendMusicList = new ArrayList<>(); if ("metal".equals(style)) { metalMusicRecommendService.recommend(); } else if ("country".equals(style)) { countryMusicRecommendService.recommend(); } else if ("grunge".equals(style)) { grungeMusicRecommendService.recommend(); }else { popMusicRecommendService.recommend(); } return recommendMusicList; }}改造后，如果有了新音乐风格推荐的需求，只需要增加相应的 xxxMusicRecommendService 类。然后在 RecommendMusicService 中增加相应分支即可。这样就做到了开闭原则。那么还有什么违背设计原则的地方吗？RecommendMusicService 是不是依赖的 xxMusicRecommendService 类太多了？没错，而且这么多类，实际上都是做推荐的事情，且都是通过 recommend 方法提供推荐结果。这完全可以抽象出接口，比如 MusicRecommendInterface。那么 RecommendMusicService 依赖 MusicRecommendInterface 就可以了。这解决了依赖反转问题----应该依赖接口，而不是依赖具体实现。我们又复习了单一职责和依赖反转原则。不愧是指导设计模式的原则，真的是无处不在。依赖 MusicRecommendInterface 没问题，但是不同的音乐风格，怎么能实例化 MusicRecommendInterface 的某个具体实现呢？工厂模式于是就应运而生了！