为什么要重写？其实设计模式已经被写烂了，基本上，网络上都是一抄一大篇，当然，我之前也是用了很多别人的文章（还好备注了，是别人写的，不然就是抄袭了）！我重写的原因，其实是想加入一些自己平时学习，工作中，遇到的情况。然后怎么想到用这个模式，或者我用了某个模式，后来一查，卧槽，原来早就有人这么用了。

我就不按网上那些资料写了，按自己的方式写了。

先说一下场景吧，我一个项目中，用到了蓝牙。其中一个模块是：蓝牙扫描功能,伪代码是这样的

1.检查蓝牙是否开启

if(bleIsOpen){

1.1蓝牙开启：扫描附近蓝牙

scanBle()

}else{

1.2蓝牙未开启：打开蓝牙

openBle()

}

2.处理蓝牙扫描结果

doScanResult(Device device)

扫描模块基本的功能就是这样，但是，在1.1这一步的时候，发现，扫描这个功能，其实，是有几种情况的，

首先是低功率和正常功率问题：这是蓝牙的扫描模式，低功率模式，快，省电，但（不稳定，但这个问题，通常会忽略，因为就算不稳定，但基本能连上），正常功率模式相对慢，耗电，但稳定;

然后就是版本问题，高版本API和低版本API之间的不兼容：Android5.0之后，有一种更高效，更稳定的低功率扫描，但是低版本，没有这一套API。

针对上述问题，所以，就需要重新做一些调整。

1.检查蓝牙是否开启

if(bleIsOpen){

1.1蓝牙开启：扫描附近蓝牙

1.1.1根据API版本高版本还是低版本扫描模式

if(isHeigh){

scanBleByHeighAPI()

}else{

scanBleByNorAPI()

}

}else{

1.2蓝牙未开启：打开蓝牙

openBle()

}

2.处理蓝牙扫描结果

doScanResult(Device device)

这个时候，网上的资料通常会说，这样改之后，还是会有问题的，就是如果后面又有新的扫描模式，又要加判断，破环结构什么的。说实话，其实，个人觉得，这个理由不够充分，我真不会为了这个东西，去强行改代码。因为，就算这么写，又有什么关系，业务照样是能实现的。

但是，我还是要在改一下，原因是：

1.从代码阅读和业务代码的角度而言，应该更纯粹一点。业务代码，只写业务。因为这里，扫描和处理扫描结果，都是属于业务代码，但是，怎么扫描，怎么处理结果，那是实现的问题，应该抽取出去。

2.扫描和处理结果，应该是成对的（或许结果都是一样，但是不排除，API的处理方式不同，或者有什么新的更新，导致处理方式不同，这一点是因为吃了百度地图API的亏）

ok，就这两个理由，让我决定要改它。

然后，我就这样改了

当然，代码没有写得很完整，旨在描述这个过程，业务。

好了，最后再总结一下（网上那些一抄一大篇的写法）：

优点

模板方法模式通过把不变的行为搬移到超类，去除了子类中的重复代码。

子类实现算法的某些细节，有助于算法的扩展。

通过一个父类调用子类实现的操作，通过子类扩展增加新的行为，符合“开放-封闭原则”。

缺点

每个不同的实现都需要定义一个子类，这会导致类的个数的增加，设计更加抽象。

适用场景

在某些类的算法中，用了相同的方法，造成代码的重复。

控制子类扩展，子类必须遵守算法规则。

上述，是网上抄过来的，基本都是这么写的。面试，可以这样答，不过，感觉没什么卵用。

但是，我自己的总结是：

优点

业务代码在父类（抽象类），技术代码（实现）在子类；

调用更简单，忽略细节，直观业务逻辑；

缺点

不会用，你就写不来。（什么子类多之类的问题，只要你把包分好了，归类做好，也不存在的）

场景：

看个人理解，我已经举了一个工作中的实例了。基本来说就是，同一个功能（方法），多种实现方式，用这个，基本都可以。