判斷配件是否需要抽檢，現在系統有三種抽檢規則：商品規則，組織規則，其它規則，配件滿足任一規則即需要抽檢
因為配件要依次經過三種規則，所以考慮使用責任鏈模式：讓配件依次匹配商品規則，組織規則，其它規則，滿足任一規則即返回，不滿足繼續用下一規則判斷。
**結構：
1.策略模版，建立乙個抽象類：commoninspectionhandler
/**
* 抽檢規則處理器
*/@slf4j
public abstract class
commoninspectionhandler
/** * 給當前物件指定下一處理人，並返回【下一處理人】
*/public commoninspectionhandler setnextcommoninspectionhandler
(commoninspectionhandler next)
/** * 明細判斷是否需抽檢：核心方法dochain:如果當前translinequeryhandler可以解決，就解決，如果不行，就調此方法交給next去解決
* @param inspectionorderdetaildtos 抽檢明細
*/public final void
dochain
(list inspectionorderdetaildtos)
//如果還有配件不需要抽檢&&還有抽檢規則未匹配，匹配下一抽檢規則（繼續責任鏈）if(
getnextcommoninspectionhandler()
!=null)}
/** * 判斷配件是否需要抽檢：抽象方法deal：用於處理請求，所有處理人都要根據自身條件重寫此方法
* @param inspectionorderdetaildtos 抽檢明細
* @return 需要抽檢的orderdetailids
*/public abstract list
deal
(list inspectionorderdetaildtos)
;}
方法1：gethandlerbiztype(),區分處理物件
方法2：setnextcommoninspectionhandler(),設定當前處理物件的下一處理物件
方法3：deal(),抽象方法，處理請求
方法4：dochain(),用於將引數傳遞給下乙個處理物件(根據 需求可定製化，此處判斷配件是否需要抽檢，如果已滿足抽檢條件，結束鏈路返回，如果未滿足抽檢條件，將資料轉交給下一處理物件)。
其中列舉類：inspectionruleoperationbiztypeenum：
/**
* 抽檢規則操作記錄型別列舉
*/public
enum inspectionruleoperationbiztypeenum
}
a.商品抽檢規則處理器:goodsrulehandler
/**
* 商品抽檢規則處理器
*/@slf4j
@component
public
class
goodsrulehandler
extends
commoninspectionhandler
@override
public list
deal
(list inspectionorderdetaildtos)
是否需要抽檢"
, inspectionorderdetaildtos.
stream()
.map
(o->o.
getorderdetailid()
).collect
(collectors.
toset()
)); log.
info
("邏輯**省略，如果配件符合某商品規則，就給配件打上需要抽檢的標籤");
return inspectionorderdetaildtos;}}
;
/**
* 組織抽檢規則處理器
*/@slf4j
@component
public
class
orgrulehandler
extends
commoninspectionhandler
@override
public list
deal
(list inspectionorderdetaildtos)
是否需要抽檢"
, inspectionorderdetaildtos.
stream()
.map
(o->o.
getorderdetailid()
).collect
(collectors.
toset()
)); log.
info
("邏輯**省略，如果配件符合組織規則，就給配件打上需要抽檢的標籤");
return inspectionorderdetaildtos;
}}
/**
* 其他抽檢規則處理器
*/@slf4j
@component
public
class
otherrulehandler
extends
commoninspectionhandler
@override
public list
deal
(list inspectionorderdetaildtos)
是否需要抽檢"
, inspectionorderdetaildtos.
stream()
.map
(o->o.
getorderdetailid()
).collect
(collectors.
toset()
)); log.
info
("邏輯**省略，如果配件符合其他規則，就給配件打上需要抽檢的標籤");
return inspectionorderdetaildtos;
}}
public
class
inspectionruletest
extends
basetest
}}
<1> 開始使用商品規則,判斷[1222]是否需要抽檢
邏輯**省略，如果配件符合某商品規則，就給配件打上需要抽檢的標籤
<2> 開始使用組織規則,判斷[1222]是否需要抽檢
邏輯**省略，如果配件符合組織規則，就給配件打上需要抽檢的標籤
<3> 開始使用其他抽檢規則,判斷[1222]是否需要抽檢
邏輯**省略，如果配件符合其他規則，就給配件打上需要抽檢的標籤
配件大燈是否需要抽檢：false
策略模式在工作中應用
物流系統要新增包裹資料，現在物流的上游有三種包裹 線上的包裹，線下的包裹，外部的包裹，每種包裹在新增時會有些不同的操作，比如線上線下的包裹新增後要發訊息給訂單履約中心方便監控，線上包裹新增時要判斷包裹是否需要抽檢，釘箱，並生成相關的資料等。每種包裹都有其特殊的操作，從系統維護的角度上說，可以使用策略...
策略模式在工作中的應用
最近在日常工作過程中接到乙個任務 需要提供乙個介面，根據不同的意圖返回給客服端不同的答案，每個意圖去識別答案的演算法都有各自不同的邏輯。作為乙個合格的crud程式設計師，接到這個需求腦袋裡的第一反應就是用if else去實現，但是這樣寫 太醜陋了，每個else裡面都會有大量的業務邏輯，對於後期接坑的...
設計模式在工作中的應用（二）
這裡我們不介紹如何進行解析生成sql語句，怎麼解析的不重要，只要知道這些都是解析類，轉換為sql語句的不同部分。我是想說說針對上面的需求，我是如何考慮的。需要能夠使用sqlserver的函式？大概想一想，感覺很容易啊，不就是封裝乙個函式類，實現sqlserver資料庫的函式。是的，最根本的實現也就是...