这是一个创建于 4036 天前的主题，其中的信息可能已经有所发展或是发生改变。
事情是这样的，原来的代码是这样：
$login = new ILogin();
$uid = $login->getLoginUid();
if ($uid < 10000) {
return json_encode(array('ret'=>-1));
}
我改成了这样：
$login = new ILogin();
$uid = $login->getLoginUid();
if ($login->hasError()) {
return json_encode($login->getErrorl());
}
说我没事瞎JB调用这么多函数干啥，明明可以一步到位的。
我解释：这样方便维护，而且语义强。
他说：你这个太多调用方法，速度慢。
我:.....
我就是喜欢OOP， 但不知道这种情况改怎么反驳
$login = new ILogin();
$uid = $login->getLoginUid();
if ($uid < 10000) {
return json_encode(array('ret'=>-1));
}
我改成了这样：
$login = new ILogin();
$uid = $login->getLoginUid();
if ($login->hasError()) {
return json_encode($login->getErrorl());
}
说我没事瞎JB调用这么多函数干啥，明明可以一步到位的。
我解释：这样方便维护，而且语义强。
他说：你这个太多调用方法，速度慢。
我:.....
我就是喜欢OOP， 但不知道这种情况改怎么反驳
第 1 条附言 2014-11-07 11:40:30 +08:00
统一回复下：
1.有人可能光看这一段代码去了。 我现在设计的所有的model里面只要有false的，都会调用 :
$this->setError(errorCode,array('msg'=>'数据不存在'));
2.昨天有用xhprof测试过, 10000次， 第二种是第一种的调用时长的2倍。
3.我一直觉得我的写法是对的。但对方掐我死穴，调用太多方法效率比起他那个稍显不足这一点我无法反驳。 我弱弱的说我的方便维护，好像不起啥作用。我只是想请教各位遇到这种情况怎么说服别人。。。。。。
1.有人可能光看这一段代码去了。 我现在设计的所有的model里面只要有false的，都会调用 :
$this->setError(errorCode,array('msg'=>'数据不存在'));
2.昨天有用xhprof测试过, 10000次， 第二种是第一种的调用时长的2倍。
3.我一直觉得我的写法是对的。但对方掐我死穴，调用太多方法效率比起他那个稍显不足这一点我无法反驳。 我弱弱的说我的方便维护，好像不起啥作用。我只是想请教各位遇到这种情况怎么说服别人。。。。。。
 | 1 chmlai 2014-11-07 11:03:05 +08:00 速度慢~哈哈哈 |
 | 2 pykwokcc 2014-11-07 11:10:06 +08:00 让我来写，我也会写成楼主的写法 |
 | 3 yxz00 2014-11-07 11:10:06 +08:00 我倒是觉得原来那个版本好些。只不过把那个magic num改成login的属性maxid就好了。 |
| 4 yxz00 2014-11-07 11:10:38 +08:00 这个跟oop也没什么关系 |
 | 5 haiyang416 2014-11-07 11:11:17 +08:00 via Android 从这几行代码里我没看出你拿 uid 做什么呀，第一个反倒很明白。 我始终觉得不是为了面向对象而面向对象，不是所有东西都需要封装。 这仅对你给的几行代码而言，团队项目的话一切按约定来，个人项目随便了。 |
 | 6 sivacohan PRO 我写成类似上面那个被喷了。 咱俩换公司把。 |
 | 7 jemyzhang 2014-11-07 11:16:03 +08:00 国内很多都喜欢简单,而不考虑维护性. 记得之前在微信上绑定招行信用卡,硬是绑定不上,弹出错误说我没开卡.后来和客服妹妹过了N天的招,并且后台维护也介入了,还是没解决. 最后的最后的最后才发现原来是我没设定查询密码. 我只想说,去你妹的没开卡,错误信息是这样做的么?! 赞楼主~ |
 | 8 fengliu222 2014-11-07 11:17:04 +08:00 无法评判这两段代码的好坏。 你写的那段，$uid压根儿没用上。 还有就是，把错误封装成一个方法hasError是否有必要，是要看错误码的多少，如果错误情况比较多，那么集中处理判断确实挺好的。如果只有一个，就有点设计过度了。。 |
 | 9 PrideChung 2014-11-07 11:20:19 +08:00  1 如果是我就一定会用看小狗的眼神看着他说：“要不要给你介绍几本程序设计的入门书？” |
 | 10 patr0nus 2014-11-07 11:20:45 +08:00 搭配LZ头像看贴风味更佳;) |
 | 11 zakokun 2014-11-07 11:21:38 +08:00 我倒是觉得原来那个语义简介好理解....不过楼主的话配合你的头像很有喜感 |
 | 12 hslx111 2014-11-07 11:24:40 +08:00 这个代码没有上下文，很难判断谁对谁错 |
 | 13 cxshun 2014-11-07 11:27:49 +08:00 就一行调用还真没必要了。但以速度慢来反驳，只能说哈哈了。 |
 | 14 leiz 2014-11-07 11:28:32 +08:00 如果< 10000和 ret -1那个用的地方很多，从维护的角度看，你的做法是对的。不然等以后维护的时候，接手的人哭死。 如果只是一两处，看喜好。我个人会偏向你的写法，否则以后要调整这些错误体系的话，折腾死。 |
 | 15 chemzqm 2014-11-07 11:35:55 +08:00 OO的思路更适合功能复杂的产品，简单的调用更适合糙快猛的项目，如果需求多变项目，真没必要过度封装，只会增加所有人的理解成本。 |
 | 16 fising 2014-11-07 11:38:19 +08:00 真是啥都能喷。。。 |
 | 17 bingu 2014-11-07 11:44:54 +08:00 支持楼主派和反对楼主派梅花间竹地出现了。 |
 | 18 levn 2014-11-07 11:46:00 +08:00 1 快，把json_encode也封起来 |
 | 19 curiousjude 2014-11-07 12:02:49 +08:00 @fengliu222 楼主这只是一个代码片段而言，都hasError了，uid当然是没有啦。另外，错误码的多少不一定是一成不变的，系统复杂后，可能的错误情况也会增多。 |
 | 20 tedeyang 2014-11-07 12:10:56 +08:00 1 1，用uid兼做错误代码也真是醉了。这种代码已经不是维护性差的程度，是二义性错误。 2，性能问题有个经典答案：如无必要，不需优化。优化了方法调用的几个纳秒对以ms计的HTTP网络传输有什么意义？要快请用opcode，用java，用C。 3，你的代码也很烂。model、validation、error不应该这么耦合。如果遇到允许为false的字段，你这个机制就出问题了。 这么喜欢OOP，还不转投java阵营？Spring、Annotation、Bean的设计在解决你这个问题上甩了几条街。。。 |
 | 21 jox OOP是啥谁来告诉我 |
 | 22 RemRain 2014-11-07 12:41:19 +08:00 1 hasError 不是面向过程的方法么，OOP 的话，抛个异常吧 |
 | 23 johnsneakers OP @tedeyang 可能我这里给的例子不对，总之原来项目的代码全是如下这种： contronller: $obj = new Model(); $userinfo = array(); $ret = $obj->getUserInfo(&$userinfo); //这里引用传递,只是直观，语法错误请无视。 if($ret < 0) { return json_encode(array('ret'=>$ret)); } 另外我model里面没有写error方法哦， 所有model都有父类， error方法都是在父类里面， 这里不详细帖了。。。。 请大神指教 |
 | 24 loryyang 2014-11-07 12:57:34 +08:00 过早的性能优化是罪恶的源泉，特别是为了性能而去牺牲系统架构优雅性，增加模块耦合，降低代码可读性、易维护性等。当然，如果没有后面这些损失，你当然应该写更高效的代码。 很多时候你根本不会知道最影响性能的是哪部分代码。你过早的优化，也许只是优化了占总耗时1%的那部分代码。 关于你这个代码，我觉得原来的代码也还可以，oop不是解决问题的唯一方式，不用oop也一样可以写出好代码。你们两位支撑自己观点的原因都不太合适。最重要的还是代码的合理性，这部分错误code处理的逻辑本该属于谁，后续很可能出现的扩展是否方便支持，代码是否可以简洁易懂，是否会带来冗余代码。 |
 | 25 tabris17 2014-11-07 12:59:27 +08:00 I打头的不应该都是interface么 |
| 26 tabris17 2014-11-07 13:01:53 +08:00 另外回答呵呵就好了 |
 | 27 eric_zyh 2014-11-07 13:04:21 +08:00 看场景 1.如果 $uid < 10000 是一个常用的判断，实现成一个函数是很方便维护的。 2.如果只是在一两处地方有这个判断，就没有必要了。把只出现一、两次的都弄成函数，那维护起来反而不知道每个函数的含义。 如@tedeyang 所说的，这种代码考虑效率问题，那就太矫情了。。 |
 | 28 kmvan 2014-11-07 13:04:58 +08:00 lz 这段代码是干啥的呢？是要判断用户是否登录？还是要验证登录信息是否正确？如果是判断登录，不就一个函数可以搞定吗？如果是验证登录信息，我觉得 wp 那种比这个更好理解。 |
 | 29 zhouzm 2014-11-07 13:37:51 +08:00 1 抛开性能问题不谈，第二种写法，明显是对对象理解有问题，只是对第一段代码的形式上改写。 既然对象方法可能会有异常结果，那就不应该直接取值，应该是首先执行方法，由方法返回状态，如果成功，取值，不成功，则返回错误信息： $login = new ILogin(); if !($login->doLogin()) { return json_encode($login->getErrorl()); } $uid = $login->getLoginUid(); 反观第一段代码没有任何问题，由返回值来代表状态，改进的话只要把“array('ret'=>-1)”改为$login->getErrorl()就解决了错误信息封装的问题。 根本不是什么 OOP 的问题，是逻辑问题，楼主你好好思考一下。 |
 | 30 dbfox 2014-11-07 13:47:29 +08:00 我觉得只要能发挥出OOP的好处，就可以用OOP |
 | 31 raincious 2014-11-07 13:58:06 +08:00 1 @chemzqm 这不是过渡封装。 https://gist.github.com/raincious/037f56d050ae92f01aa6 我觉得楼主唯一的问题是 if ($login->hasError()) { 这句定义的不明确，什么都是hasError。如果非要这样不如throw一个异常然后一个一个catch。 另外关于性能，那东西不是交给编译器优化的么？不要尝试过渡优化你的程序（微优化大部分情况下只是在浪费时间），应该尽量写出易于（让别人乐于）阅读的代码。 |
 | 32 bombless 2014-11-07 14:52:27 +08:00 看什么产品什么公司吧，改动的比较猛的自己就会改一种写法，没有动力改其实也说明对可维护性的要求也不那么急迫 |
 | 33 feinux 2014-11-07 15:27:24 +08:00 要我说，代码写出来是要用程序实现的。程序是给用户用的。用户是人。所以归根到底，他妈的你返回一句人看不懂的提示，老子用你的程序干蛋啊？除非是国企这种的，花大价钱搞来非用不可。 最讨厌一类程序员就是图自己省事儿，为难用户。还自己觉得自己很牛逼，用户是傻逼不懂。用户是不懂，用户可以不用啊？放着那么多好的程序不用，老子干吗委屈自己？ 你把这段话复制过去，就说是我说的。 |
 | 34 rwx 2014-11-07 15:55:36 +08:00 这是技术问题吗？这明明是人的问题 不是所有人都喜欢被别人无故改掉自己的代码，那是很直白的在告诉他：你写的真烂 不喷你喷谁。。 |
 | 35 princecauchy 2014-11-07 16:06:01 +08:00 @jox object-oriented programming 面向对象编程。 |
 | 36 latyas 2014-11-07 16:13:20 +08:00 原来的代码运行的好好的何必修改。 |
 | 37 ren2881971 2014-11-07 16:18:33 +08:00 也不是ｏｏｐ啊 就是封装了下函数而已。 但是我觉得ＬＺ这种做法是对的！ 告诉那个人 万一 $uid < 10000 这个条件变了 且不是应用中所有的代码都挨个检查下更改了？ 封装成方法 直接改方法内部就可以啦啊。 |
 | 38 palxex 2014-11-07 16:52:52 +08:00 @jemyzhang 这个。。。招行信用卡的查询密码原来可以不设的么？我记得办卡时就设好了啊。（不是说交易密码啊，那个确实可以不设，而且我从来不设，绑定微信也没发现问题。） |
 | 39 pljhonglu 2014-11-07 16:54:38 +08:00 1 如果多处靠判断 uid 来判断正确性，那可以单独封装。否则还是觉得第一种比较直观。大项目为了可维护性必须要多封装。小工程本来模块间的耦合度就低，没必要过度封装。 另外，同意上面的说法，OOP的写法应该是抛异常 |
 | 40 dreampuf 2014-11-07 17:02:24 +08:00 1 - 除了正确执行，代码就是用来维护的。谈维护有个标准，就是谁都能执行，大家品味一致 - 你能兼容他的hard code，他未必能兼容你的OOP - 除非没人愿意接手维护了，或者有强力Leader牵头，不要干重构这类吃力不讨好的事儿。Martin 的书有点像心灵鸡汤，描绘了该是什么什么样。问题是design一旦脱离实际执行的人就变了味道，执行不好，培训不够，监督不全都会慢慢变坏。 - 没有数据，“可维护性”很有可能不可度量。比起明眼就能看出来的调用效率，自然被攻击。你需要想办法证明“这样写”的代码不可维护。 |
 | 41 konakona 2014-11-07 17:07:45 +08:00 楼主应该是再没有了解业务环境的情况下妄自修改的。 如果说这是QQ登录，10000以前的不让用因为那是内部帐号，原来的代码将很好的表明这一点，而不需要翻来翻去甚至不用注释。 你改了以后反而费解。 并不是什么东西都要封装的。 |
 | 42 barbery 2014-11-07 17:13:50 +08:00 大部分情况下，楼主这样写是对的。。。 |
 | 43 zythum 2014-11-07 17:40:14 +08:00 他喵的这个和oop有半毛钱关系 |
 | 44 coofly 2014-11-07 17:47:32 +08:00 $login = new ILogin(); $uid = 0; if ($login->getLoginUid(&uid)) { //use uid and other } else { return json_encode(array('ret'=>-1)); } 两个都有问题 感觉应该这么写吧？ 让getLoginUid返回成功与否不就好了 不会php，可能有谬误 |
 | 45 ruchee 2014-11-07 18:24:00 +08:00 via Android 第一种容易理解，也方便以后的维护，实在没必要去取错误记录绕弯子 |
 | 46 railgun 2014-11-07 18:31:59 +08:00 具体情况具体分析咯，反正编程就是在可维护性和性能之前找平衡 |
 | 47 hitsmaxft 2014-11-07 21:40:58 +08:00 我觉得吧, 为了方法而方法确实是浪费性能, 也谈不上什么oop, oop得解决具体场景才谈得上设计, 你这连问题都算不上, 只是个方法调用而已 判断一个登录失败, 调用了n个方法, 也没啥必要. 在登录失败的情况下, 直接给login加个属性 $login = new ILogin(); if (!$login->done) { return ILogin::JSON_FAILED } |
 | 48 ryd994 2014-11-07 22:03:35 +08:00 via Android 你可以搭个脚手架和他比比性能差多少。如果 |
 | 49 ffffwh 2014-11-08 00:40:52 +08:00 OOP核心要义：多态。 |
 | 50 herozzm 2014-11-08 01:36:45 +08:00 个人觉得，如果只是部分改造，赞成第一种写法，如果是全部重构，我赞成第二种写法 |
 | 51 julyclyde 2014-11-08 18:28:05 +08:00 总感觉俩都挺怪的 |
Select Language