一種通過硬體設備的數據用了特殊格式，前一段是id，後一段是數據，
前面一段，代表它是一段類型為A, B, C等等哪一種類型的資料。
根據前面的類型，我們取後面中的某幾位，如A類型我們需要資料取資料的1-3位，B類型則需要第20和第22位。
現在設計的時候只需要能接受a類和b類就行了，但是未來想要接受c類, d類等等，同時對數據進行的操作也不同，比如a類需要把1-3位都乘二，b類第二十位加1，第二十二位不變z
問題是應該怎麼樣設計，未來拓展的時候方便呢？例如我想支援d類，不用重寫程式碼....
複雜的話用策略模式，不複雜的直接OO的繼承，不同類型的訊息交給不同的子類別去處理。
應該把資料協定格式規定好：例如：高3位代表類型，中間2位代表協定版本，後面代表資料。 協定規定好後，透過模板方法來處理，將具體解析放到子類，通用的放到父類。 這樣在擴充時，不需要改動原有程式碼，只需要寫新的實作就可以。
根本用不到設計模式，傳統的繼承就可以，各個子類別分別取不同的欄位就可以。
如果一定要使用設計模式，可以考慮一哈策略模式
還需要判斷一下後續的使用者，工廠模式，策略模式，代理模式可能都能滿足你擴展的需求，其實重要的是想法，遵照六原則設計吧，沒必要非要套某一個模式，根據需求，程式碼慢慢演變，最後可能自然的就符合某個模式了，也可能是多種模式的組合。
複雜的話用策略模式，不複雜的直接OO的繼承，不同類型的訊息交給不同的子類別去處理。
應該把資料協定格式規定好：例如：高3位代表類型，中間2位代表協定版本，後面代表資料。
協定規定好後，透過模板方法來處理，將具體解析放到子類，通用的放到父類。
這樣在擴充時，不需要改動原有程式碼，只需要寫新的實作就可以。
根本用不到設計模式，傳統的繼承就可以，各個子類別分別取不同的欄位就可以。
如果一定要使用設計模式，可以考慮一哈策略模式
還需要判斷一下後續的使用者，工廠模式，策略模式，代理模式可能都能滿足你擴展的需求，其實重要的是想法，遵照六原則設計吧，沒必要非要套某一個模式，根據需求，程式碼慢慢演變，最後可能自然的就符合某個模式了，也可能是多種模式的組合。