C_and_CPP 板


LINE

有遇到一个程式流程中 某些步骤可能要检查或不检查的问题 想请问该 怎麽写比较好. 语言是使用C++ 首先我有一个computing class, 里面有个member function, 专门负责做计算的动作 而里面有七个步骤: class Engine::compute(...arguments...) 1. compute1 2. compute2 3. if checking fails this return pre-condition is not satisfied 4. compute3 5. foreach cofig in allowed_user_configurations 6 if checking succeed then store this configuration 7. return allowed_configuration 步骤3)跟步骤6)的检查是由一个complianceChecker的class来做的: bool compliance.check(....arguments....) 现在呢 为了一些原因 提供了一个选项 可以让步骤3.)跟步骤6.)的检查不做-也就是 永远检查成功, 请问要怎麽在不动到主流程的状况下, 来达成这件事情呢? 因为这边是简化版本 但其实检查的地方大概十多处.... 全部都加if-else好像不是太好 如果考虑到未来在其他部分需要加检查 或是未来 流程异动 这样if-else很容易漏掉 或是忘记要加if-else 目前我的想法是 加一个wrapper class在compliance checker上 ctor吃一个要不要 做检查的boolean, 然後有一个perfect forwarding的 member function取代掉 原本的 compliance checker的check function(转call): class wrapper { public: wrapper(bool doCheckIn): doCheck(doCheckIn) {} template <typename ... Args> bool check(Args&& ... args){ return !doCheck || checker.check(std::forward<Args>(args) ... ); } private: compliance checker bool doCheck; } 然後在第一行之前生成这个wrapper, 用这个wrapper取代掉步骤3.)跟步骤6.)的 compliance class: class Engine::compute(...arguments...) ==> 0. wrapper newChecker(doCheckOrNot); 1. compute1 2. compute2 => 3. if (!newChecker.check(...)) return the pre-condition is not satisfied ...................... 5. foreach cofig in allowed_user_configurations ==> 6. if (newChecker.check(....)) then store this configuration 7. return allowed_configuration 目前这个做法有一些好处: 1. 不动到compliance checker, 而且也不用怕compliance checker的interfance of check function会改变(用template+perfect forwarding处理掉了) 2. 整个流程不变 逻辑上也很分明 就是有检查跟永远成功这两种 但是有些不顺的地方: 1.这个wrapper class定位很尴尬, 不知道要当作一个放出来给大家用的class 或是该 跟谁绑在一起 绑在一起是指逻辑关系上.......现在wrapper class九成像syntax sugar 我直接放在CPP file的 anonymous的namespace里 XDDDDD 未来 若别的地方遇到同一种状况 是不是又要写一次? 要不然就要把这个有template的 wrapper class放在header, 但这样会引进compliance class的dependency..... 2. 要改写成virtual function的形式吗? 这样可继承之类的 但因为有用到template所以 没法用virtual function, 而且只有两种状况 用virtual是否有效益呢? 3. wrapper class生成後 就决定他的行为了(由ctor的参数决定) 要动态变化就得再多 一组setter/getter. 想要动态变化的理由是 这样wrapper可当作一个member variable.. 不知道要当作local variable还是member variable比较好...... 其实觉得这种状况应该是一个非常标准且常见的状况(二选一) 只是不晓得一般是怎麽 处理的 觉得应该是继承+virtual function处理居多吧? 但个人比较倾向少用继承 先尝试template + 组合的方式, 或是virtual function是做在别的地方的方式 P.S. compliance checker是我们动不了的一个class....... 在此 想请各位给一些想法跟建议~~~谢谢~~~ --
QR Code



※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 1.164.105.187 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/C_and_CPP/M.1698596742.A.6F2.html ※ 编辑: saladim (1.164.105.187 台湾), 10/30/2023 00:26:06 ※ 编辑: saladim (1.164.105.187 台湾), 10/30/2023 00:29:29
1F:推 CoNsTaR: 你这个这麽 procedure 的东西,如果是 business logic 就 10/30 08:41
2F:→ CoNsTaR: 照着 business logic 的架构写,例如如果 business logic 10/30 08:41
3F:→ CoNsTaR: 在这边就是每次都先确认是否做检查,那你就照着它架构写 10/30 08:41
4F:→ CoNsTaR: ,每个检查外面都包上 if else,不要做一些自以为聪明的" 10/30 08:41
5F:→ CoNsTaR: 设计" 10/30 08:41
6F:→ CoNsTaR: 如果 business logic 在这边有做抽象,例如要检查和不检 10/30 08:41
7F:→ CoNsTaR: 查被分成两种不同的流程,在不同情况下使用,两种流程有 10/30 08:41
8F:→ CoNsTaR: 各自的名字,那就把两种流程分成两个函式,不要自以为写 10/30 08:41
9F:→ CoNsTaR: 成一个函式 reusing 很聪明 10/30 08:41
10F:→ CoNsTaR: 如果这不是 business logic 而是你为了达成 business log 10/30 08:41
11F:→ CoNsTaR: ic 而写出来的演算法,那我只能说真的惨 10/30 08:41
12F:→ saladim: 意思是说直接if-else吗? 比起继承我还比较可以接受 继承 10/31 03:17
13F:→ saladim: 太难model了 对了 这边是简化过的程式 实际上复杂许多 很 10/31 03:19
14F:→ saladim: 多地方要考虑加 基本上是一个template+strategy pattern 10/31 03:20
15F:→ saladim: 的组合 设定/caller无关的都拿掉了 不是单单一堆function 10/31 03:21
16F:→ saladim: call..另外我的一个疑问就是 通常有个二选一的选项 但是 10/31 03:22
17F:→ saladim: 要嘛做个抽象有点多余(因为永远不会有更多选项) 要嘛 无 10/31 03:24
18F:→ saladim: 法用现有体系去model这个抽象 或是它本身就是一个独立的 10/31 03:25
19F:→ saladim: 不知道一般是怎麽处理 这个case, 因为流程固定了所以两个 10/31 03:27
20F:→ saladim: 是不行的......以上....大概补充说明一下..... 10/31 03:28
21F:推 CoNsTaR: 你比较可以接受继承的具体原因我没看到? 10/31 11:07
22F:→ CoNsTaR: 如果你对 if else 的 concern 只是像你内文说的"怕以後 10/31 11:07
23F:→ CoNsTaR: 忘记加",那你可能要再想想,我不太能理解忘记做该做的工 10/31 11:07
24F:→ CoNsTaR: 作是个什麽概念 10/31 11:07
25F:→ CoNsTaR: 1. 你用 if else 不会影响未来制定 business logic 的人 10/31 11:07
26F:→ CoNsTaR: 考虑到检查/不检查两种情况 10/31 11:07
27F:→ CoNsTaR: 2. 也不会影响未来写 jira ticket 的时候的 description 10/31 11:07
28F:→ CoNsTaR: 和 acceptance criteria 忘记这两种情况 10/31 11:07
29F:→ CoNsTaR: 3. 也不会影响原本该做的 code review 变成没做 10/31 11:07
30F:→ CoNsTaR: 4. 也不会影响 unit tests 忘记测 10/31 11:07
31F:→ CoNsTaR: 5. 也不会影响 testers 的 test plan 忘记加这个测项 10/31 11:07
32F:→ CoNsTaR: 完全看不出来怎麽会影响任何一个人忘记考虑检查/不检查 10/31 11:07
33F:→ CoNsTaR: 两种情况 10/31 11:07
34F:→ CoNsTaR: 看你的内文和回覆感觉最大的问题是你在用写通用函式库的 10/31 11:07
35F:→ CoNsTaR: 思维写 user code,这样写出来的东西不觉得就像是用营造 10/31 11:07
36F:→ CoNsTaR: 业 sop 盖的叠叠乐一样吗 10/31 11:07
37F:推 wulouise: 不懂你说的忘记加是什麽情况,多了cpmpute忘记补检查? 10/31 12:32
38F:→ wulouise: general就是所有compute都有check,只是chk可以noop 10/31 12:33
39F:→ wulouise: 或所有compute跟check都当做callback执行,继承没有必要 10/31 12:35
40F:→ wulouise: 如果对效能有需求,那看情况决定要不要generalize 10/31 12:36
41F:→ wulouise: 重点是你的抽象化可以用在别的地方吗?好debug吗? 10/31 12:38
42F:推 Dracarys: 改用rust的operator? 11/01 09:06
43F:→ saladim: 继承对我的顺位会在第二或更之後 怕忘了加是有了这logic 11/02 03:14
44F:→ saladim: 在 若是要改or加新的处理(不是其他bussiness logic变动) 11/02 03:15
45F:→ saladim: 在做check的时候 可能会忘记有这条 实际的东西还蛮多的若 11/02 03:16
46F:→ saladim: 不是用同一个util(不管是func or class) 会有机会漏掉 11/02 03:18
47F:→ saladim: 当然1~5也有道理 其他大大建议我也会一并想一想 其实不到 11/02 03:21
48F:→ saladim: 写通用函式库 当会很多东西常出现 但组合他们的逻辑变动 11/02 03:22
49F:→ saladim: 很快(bussiness logic/requests...) 一定会有一个自己的" 11/02 03:23
50F:→ saladim: 好用函式库/engine库" XD 才能改得快 重复使用"解" 11/02 03:25
51F:推 bizer: 最个macro取代不就好了?搞这麽复杂? 11/04 10:30
52F:推 LPH66: 我会认为这个「选项」应该要是 business logic 的一部份 11/04 12:29
53F:→ LPH66: 是的话其实也没什麽「忘了」的问题, 因为那就是没实作完全 11/04 12:30
54F:→ LPH66: 如果未来要加其他开关的话应该要以等同改变 business logic 11/04 12:31
55F:→ LPH66: 的型式去处理, 而不只是加一个开关调整这种事 11/04 12:31
56F:→ LPH66: 讲更简单一点就是, 加开关应该要以等同於改流程的程度对待 11/04 12:36
57F:→ LPH66: (实际上真的在改流程, 新增某条件之下某流程可跳过的逻辑) 11/04 12:36
58F:→ LPH66: 未来不管是加别的开关或是流程调整都要顺过整个流程才实作 11/04 12:37
59F:→ LPH66: 这样这些开关是流程的一部份, 就不会有什麽「忘记」的问题 11/04 12:38
60F:推 a731977: DP, chain of responsibility 参考看看,对於流程控管非 11/06 03:30
61F:→ a731977: 常好用 11/06 03:30
62F:推 AiriMania: 楼下板桥知名ID Elio2021 12/02 13:43







like.gif 您可能会有兴趣的文章
icon.png[问题/行为] 猫晚上进房间会不会有憋尿问题
icon.pngRe: [闲聊] 选了错误的女孩成为魔法少女 XDDDDDDDDDD
icon.png[正妹] 瑞典 一张
icon.png[心得] EMS高领长版毛衣.墨小楼MC1002
icon.png[分享] 丹龙隔热纸GE55+33+22
icon.png[问题] 清洗洗衣机
icon.png[寻物] 窗台下的空间
icon.png[闲聊] 双极の女神1 木魔爵
icon.png[售车] 新竹 1997 march 1297cc 白色 四门
icon.png[讨论] 能从照片感受到摄影者心情吗
icon.png[狂贺] 贺贺贺贺 贺!岛村卯月!总选举NO.1
icon.png[难过] 羡慕白皮肤的女生
icon.png阅读文章
icon.png[黑特]
icon.png[问题] SBK S1安装於安全帽位置
icon.png[分享] 旧woo100绝版开箱!!
icon.pngRe: [无言] 关於小包卫生纸
icon.png[开箱] E5-2683V3 RX480Strix 快睿C1 简单测试
icon.png[心得] 苍の海贼龙 地狱 执行者16PT
icon.png[售车] 1999年Virage iO 1.8EXi
icon.png[心得] 挑战33 LV10 狮子座pt solo
icon.png[闲聊] 手把手教你不被桶之新手主购教学
icon.png[分享] Civic Type R 量产版官方照无预警流出
icon.png[售车] Golf 4 2.0 银色 自排
icon.png[出售] Graco提篮汽座(有底座)2000元诚可议
icon.png[问题] 请问补牙材质掉了还能再补吗?(台中半年内
icon.png[问题] 44th 单曲 生写竟然都给重复的啊啊!
icon.png[心得] 华南红卡/icash 核卡
icon.png[问题] 拔牙矫正这样正常吗
icon.png[赠送] 老莫高业 初业 102年版
icon.png[情报] 三大行动支付 本季掀战火
icon.png[宝宝] 博客来Amos水蜡笔5/1特价五折
icon.pngRe: [心得] 新鲜人一些面试分享
icon.png[心得] 苍の海贼龙 地狱 麒麟25PT
icon.pngRe: [闲聊] (君の名は。雷慎入) 君名二创漫画翻译
icon.pngRe: [闲聊] OGN中场影片:失踪人口局 (英文字幕)
icon.png[问题] 台湾大哥大4G讯号差
icon.png[出售] [全国]全新千寻侘草LED灯, 水草

请输入看板名称,例如:Boy-Girl站内搜寻

TOP