為什么要重寫？其實設(shè)計模式已經(jīng)被寫爛了，基本上，網(wǎng)絡(luò)上都是一抄一大篇，當(dāng)然，我之前也是用了很多別人的文章（還好備注了，是別人寫的，不然就是抄襲了）！我重寫的原因，其實是想加入一些自己平時學(xué)習(xí)，工作中，遇到的情況。然后怎么想到用這個模式，或者我用了某個模式，后來一查，臥槽，原來早就有人這么用了。
我就不按網(wǎng)上那些資料寫了，按自己的方式寫了。
先說一下場景吧，我一個項目中，用到了藍牙。其中一個模塊是：藍牙掃描功能,偽代碼是這樣的
1.檢查藍牙是否開啟
if(bleIsOpen){
1.1藍牙開啟：掃描附近藍牙
scanBle()
}else{
1.2藍牙未開啟：打開藍牙
openBle()
}
2.處理藍牙掃描結(jié)果
doScanResult(Device device)
掃描模塊基本的功能就是這樣，但是，在1.1這一步的時候，發(fā)現(xiàn)，掃描這個功能，其實，是有幾種情況的，
首先是低功率和正常功率問題：這是藍牙的掃描模式，低功率模式，快，省電，但（不穩(wěn)定，但這個問題，通常會忽略，因為就算不穩(wěn)定，但基本能連上），正常功率模式相對慢，耗電，但穩(wěn)定;
然后就是版本問題，高版本API和低版本API之間的不兼容：Android5.0之后，有一種更高效，更穩(wěn)定的低功率掃描，但是低版本，沒有這一套API。
針對上述問題，所以，就需要重新做一些調(diào)整。
1.檢查藍牙是否開啟
if(bleIsOpen){
1.1藍牙開啟：掃描附近藍牙
1.1.1根據(jù)API版本高版本還是低版本掃描模式
if(isHeigh){
scanBleByHeighAPI()
}else{
scanBleByNorAPI()
}
}else{
1.2藍牙未開啟：打開藍牙
openBle()
}
2.處理藍牙掃描結(jié)果
doScanResult(Device device)
這個時候，網(wǎng)上的資料通常會說，這樣改之后，還是會有問題的，就是如果后面又有新的掃描模式，又要加判斷，破環(huán)結(jié)構(gòu)什么的。說實話，其實，個人覺得，這個理由不夠充分，我真不會為了這個東西，去強行改代碼。因為，就算這么寫，又有什么關(guān)系，業(yè)務(wù)照樣是能實現(xiàn)的。
但是，我還是要在改一下，原因是：
1.從代碼閱讀和業(yè)務(wù)代碼的角度而言，應(yīng)該更純粹一點。業(yè)務(wù)代碼，只寫業(yè)務(wù)。因為這里，掃描和處理掃描結(jié)果，都是屬于業(yè)務(wù)代碼，但是，怎么掃描，怎么處理結(jié)果，那是實現(xiàn)的問題，應(yīng)該抽取出去。
2.掃描和處理結(jié)果，應(yīng)該是成對的（或許結(jié)果都是一樣，但是不排除，API的處理方式不同，或者有什么新的更新，導(dǎo)致處理方式不同，這一點是因為吃了百度地圖API的虧）
ok，就這兩個理由，讓我決定要改它。
然后，我就這樣改了
當(dāng)然，代碼沒有寫得很完整，旨在描述這個過程，業(yè)務(wù)。
好了，最后再總結(jié)一下（網(wǎng)上那些一抄一大篇的寫法）：
優(yōu)點
模板方法模式通過把不變的行為搬移到超類，去除了子類中的重復(fù)代碼。
子類實現(xiàn)算法的某些細(xì)節(jié)，有助于算法的擴展。
通過一個父類調(diào)用子類實現(xiàn)的操作，通過子類擴展增加新的行為，符合“開放-封閉原則”。
缺點
每個不同的實現(xiàn)都需要定義一個子類，這會導(dǎo)致類的個數(shù)的增加，設(shè)計更加抽象。
適用場景
在某些類的算法中，用了相同的方法，造成代碼的重復(fù)。
控制子類擴展，子類必須遵守算法規(guī)則。
上述，是網(wǎng)上抄過來的，基本都是這么寫的。面試，可以這樣答，不過，感覺沒什么卵用。
但是，我自己的總結(jié)是：
優(yōu)點
業(yè)務(wù)代碼在父類（抽象類），技術(shù)代碼（實現(xiàn)）在子類；
調(diào)用更簡單，忽略細(xì)節(jié)，直觀業(yè)務(wù)邏輯；
缺點
不會用，你就寫不來。（什么子類多之類的問題，只要你把包分好了，歸類做好，也不存在的）
場景：
看個人理解，我已經(jīng)舉了一個工作中的實例了?；緛碚f就是，同一個功能（方法），多種實現(xiàn)方式，用這個，基本都可以。
