作者sd016808 (sd016808)
看板C_and_CPP
標題[問題] 繼承架構設計的問題
時間Tue May 31 20:28:24 2016
開發平台(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://webptt.com/m.aspx?n=bbs/C_and_CPP/M.1464697708.A.FAB.html
1F：→ xpride: 為什麼Item要提供子類別自已專屬的介面??05/31 23:52
2F：→ xpride: 自已的事情自已做就好了。05/31 23:53
3F：→ xpride: 你提供Get/SetSize這介面，candy以外的子類別又不能用05/31 23:54
4F：→ xpride: 那幹麻要把他寫進介面裡??05/31 23:54
5F：→ sd016808: 如果item不提供子類別專屬的介面 那seller類別要如何呼06/01 01:35
6F：→ sd016808: 叫到candy或者drink專屬的method? 難道要做向下轉型嗎？06/01 01:35
7F：→ IKAFIRE: 一開始就不該透過item存取子類別的method，子類別的metho06/01 01:52
8F：→ IKAFIRE: d就以子類別的型態去存取，處理完再用item pointer接06/01 01:52
9F：→ IKAFIRE: 是說你set method的定義怎麼好像跟慣用相反06/01 01:53
10F：→ sd016808: 抱歉 set的部分寫太快寫錯了 是要改變member value 不是06/01 07:48
11F：→ sd016808: 要return value 引數的部分也忘記寫ORZ06/01 07:48
12F：→ sd016808: 一開始就用子類別去存取 是不是代表說seller打從一開始06/01 07:56
13F：→ sd016808: 就應該直接拆成candy seller 和 drink seller 然後各自06/01 07:56
14F：→ sd016808: 處理candy 和 drink類別 不要透過item去操作 然後store06/01 07:56
15F：→ sd016808: 類別身上同時擁有candy seller 和drink seller 再根據06/01 07:56
16F：→ sd016808: 不同的function來使用drink seller和candy seller就好06/01 07:56
※ 編輯: sd016808 (114.136.140.208), 06/01/2016 09:06:49
17F：→ IKAFIRE: 你可能要先解釋一下你的需求是什麼，你想要達成什麼06/01 17:01
18F：→ IKAFIRE: 你的seller用途是什麼？在這裡看來是冗餘的存在06/01 17:02
19F：→ sd016808: seller 是量測設備 store 是一群量測設備的集合 item是06/01 18:21
20F：→ sd016808: 可以被量測的產品 一台設備可以只量測一台產品 也可以06/01 18:21
21F：→ sd016808: 同時量測多台產品 client端基本上是透過store去控制所 06/01 18:21
22F：→ sd016808: 有的量測設備的動作 因為產品間的差異很大 可能是風扇 06/01 18:21
23F：→ sd016808: 需要量測轉速 可能是電源 需要量測電壓電流資訊 06/01 18:21
24F：→ sd016808: 以目前的架構 item類別會變成一種很奇怪的抽象產品 同 06/01 18:25
25F：→ sd016808: 時具備了各種不同產品的屬性 而且實際上的量測設備只有06/01 18:25
26F：→ sd016808: 一種 但是它能量測各種不同的產品 所以我在猶豫到底需 06/01 18:25
27F：→ sd016808: 不需要把設備抽象化成切成不同的seller06/01 18:25
29F：→ sd016808: 如果FanSeller要控制轉速 但是seller沒有提供這個介面 06/01 20:03
30F：→ sd016808: 那你的store要怎麼呼叫？ 我是不是應該把不同的控制方 06/01 20:03
31F：→ sd016808: 法分離成不同介面 然後讓store擁有各種不同介面的List 06/01 20:03
32F：→ sd016808: 例如List<IFanControl> List<IPowerControl> 再根據sel 06/01 20:03
33F：→ sd016808: ler對外開放面的介面決定裡面應該使用哪一個list 06/01 20:
03
※ 編輯: sd016808 (114.136.25.237), 06/01/2016 20:05:04
34F：推 IKAFIRE: 所以你要先把你的需求描述完整，不完整的需求設計出來 06/01 20:12
35F：→ IKAFIRE: 當然功能不會完整 06/01 20:13
36F：→ sd016808: 另外可以請問一下I大繪製UML所用的軟體名稱嗎？ 06/01 20:13
37F：→ IKAFIRE: 我是用PlantUML的online editor叫PlantText 06/01 20:14
38F：→ sd016808: 感謝! 主要的需求其實就是我需要控制N台多功能的儀器 06/01 20:25
39F：→ sd016808: 根據接上的不同產品 決定要使用儀器的哪些功能 例如接上 06/01 20:25
40F：→ sd016808: 風扇 就需要控制讀取轉速資訊 接上電源 要讀取電壓電流 06/01 20:26
41F：→ sd016808: 資訊 因為儀器是多功能的只要有一台就能做不同的控制 06/01 20:28
42F：→ sd016808: 所以我需要產品的class負責記錄不同產品的資訊 06/01 20:30
43F：→ sd016808: 需要儀器的class作單台儀器的控制 06/01 20:31
44F：→ sd016808: 需要一個儀器的群組的class 負責一次對全部的儀器操控 06/01 20:31
45F：→ sd016808: 最後我可能打算實做成這個樣子 06/01 20:51
47F：→ sd016808: 就是每新增一個產品別的時候得新增一個新的List就是了.. 06/01 20:54
48F：推 IKAFIRE: 這樣每增加一種device就要修改group的介面，略不方便 06/01 21:15
49F：→ IKAFIRE: 我會覺得想辦法用統一界面操作device比較有擴充性 06/01 21:16
50F：推 FrozenMoment: 覺得 group 當容器就好，device 直接給外部操作 06/01 22:05
51F：→ sd016808: 因為有些是SetALL的命令可能是透過Broadcast的方式下 06/03 19:44
52F：→ sd016808: 不是把List裡的device取出來一個一個下 所以我覺得可能 06/03 19:45
53F：→ sd016808: 還是得要有一個Group去操作或比較方便一些 06/03 19:45
54F：→ sd016808: 會 06/03 19:57