作者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/cn.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