[問題] 繼承架構設計的問題

[sd016808 (sd016808)]

開發平台(Platform): (Ex: VC++, GCC, Linux, ...) 
VC++

問題(Question)：
如連結程式碼所示，當繼承Item的產品類別越來越多

例如:餅乾、衣服、3C產品...等等，每個產品都有自己的member variable和method

用目前這樣的架構，Item類別勢必得越寫越大，而且Seller和Store也必須提供越來越多
的

method去操做產品，要如何避免此狀況發生？

是不是打從一開始就應該把Seller拆成Candy Seller和Drink Seller

以及Store拆成Candy Store和Drink Store會比較好？

程式碼(Code)：(請善用置底文網頁, 記得排版) 
http://codepad.org/PmQnpIqx

補充說明(Supplement)：
程式碼看起來可能有一點不太像C++，好一段間沒寫了，請見諒。

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 175.98.150.194
※ 文章網址: https://www.ptt.cc/bbs/C_and_CPP/M.1464697708.A.FAB.html
→ xpride: 為什麼Item要提供子類別自已專屬的介面??
→ xpride: 自已的事情自已做就好了。
→ xpride: 你提供Get/SetSize這介面，candy以外的子類別又不能用
→ xpride: 那幹麻要把他寫進介面裡??
→ sd016808: 如果item不提供子類別專屬的介面 那seller類別要如何呼
→ sd016808: 叫到candy或者drink專屬的method? 難道要做向下轉型嗎？
→ IKAFIRE: 一開始就不該透過item存取子類別的method，子類別的metho
→ IKAFIRE: d就以子類別的型態去存取，處理完再用item pointer接
→ IKAFIRE: 是說你set method的定義怎麼好像跟慣用相反
→ sd016808: 抱歉 set的部分寫太快寫錯了 是要改變member value 不是
→ sd016808: 要return value 引數的部分也忘記寫ORZ
→ sd016808: 一開始就用子類別去存取 是不是代表說seller打從一開始
→ sd016808: 就應該直接拆成candy seller 和 drink seller 然後各自
→ sd016808: 處理candy 和 drink類別 不要透過item去操作 然後store
→ sd016808: 類別身上同時擁有candy seller 和drink seller 再根據
→ sd016808: 不同的function來使用drink seller和candy seller就好
※ 編輯: sd016808 (114.136.140.208), 06/01/2016 09:06:49
→ IKAFIRE: 你可能要先解釋一下你的需求是什麼，你想要達成什麼
→ IKAFIRE: 你的seller用途是什麼？在這裡看來是冗餘的存在
→ sd016808: seller 是量測設備 store 是一群量測設備的集合 item是
→ sd016808: 可以被量測的產品  一台設備可以只量測一台產品 也可以
→ sd016808: 同時量測多台產品 client端基本上是透過store去控制所
→ sd016808: 有的量測設備的動作 因為產品間的差異很大 可能是風扇
→ sd016808:  需要量測轉速 可能是電源 需要量測電壓電流資訊
→ sd016808: 以目前的架構 item類別會變成一種很奇怪的抽象產品 同
→ sd016808: 時具備了各種不同產品的屬性 而且實際上的量測設備只有
→ sd016808: 一種 但是它能量測各種不同的產品 所以我在猶豫到底需
→ sd016808: 不需要把設備抽象化成切成不同的seller
推 IKAFIRE: http://imgur.com/nDOiMkj  這種感覺？
→ sd016808: 如果FanSeller要控制轉速 但是seller沒有提供這個介面
→ sd016808:  那你的store要怎麼呼叫？ 我是不是應該把不同的控制方
→ sd016808: 法分離成不同介面 然後讓store擁有各種不同介面的List
→ sd016808:  例如List<IFanControl> List<IPowerControl> 再根據sel
→ sd016808: ler對外開放面的介面決定裡面應該使用哪一個list
03
※ 編輯: sd016808 (114.136.25.237), 06/01/2016 20:05:04
推 IKAFIRE: 所以你要先把你的需求描述完整，不完整的需求設計出來
→ IKAFIRE: 當然功能不會完整
→ sd016808: 另外可以請問一下I大繪製UML所用的軟體名稱嗎？
→ IKAFIRE: 我是用PlantUML的online editor叫PlantText
→ sd016808: 感謝! 主要的需求其實就是我需要控制N台多功能的儀器
→ sd016808: 根據接上的不同產品 決定要使用儀器的哪些功能 例如接上
→ sd016808: 風扇 就需要控制讀取轉速資訊 接上電源 要讀取電壓電流
→ sd016808: 資訊 因為儀器是多功能的只要有一台就能做不同的控制
→ sd016808: 所以我需要產品的class負責記錄不同產品的資訊
→ sd016808: 需要儀器的class作單台儀器的控制
→ sd016808: 需要一個儀器的群組的class 負責一次對全部的儀器操控
→ sd016808: 最後我可能打算實做成這個樣子
→ sd016808: http://imgur.com/s9GqAoN
→ sd016808: 就是每新增一個產品別的時候得新增一個新的List就是了..
推 IKAFIRE: 這樣每增加一種device就要修改group的介面，略不方便
→ IKAFIRE: 我會覺得想辦法用統一界面操作device比較有擴充性
推 FrozenMoment: 覺得 group 當容器就好，device 直接給外部操作
→ sd016808: 因為有些是SetALL的命令可能是透過Broadcast的方式下
→ sd016808: 不是把List裡的device取出來一個一個下 所以我覺得可能
→ sd016808: 還是得要有一個Group去操作或比較方便一些
→ sd016808:                          會