if else 这点事

说起if else,不得不说类似type这样的属性与oop的矛盾。

近来发现过多的对象依赖type这个属性,个人感觉既然是面向对象的编程思想,何必还有要typ这个属性?有type属性,在代码中就不可避免的会用到if else来判别,if else我觉得更多的体现在面向过程编程中,当然,我不是认为if else不能用,具体问题具体分析,在银行或者电信如果不用面向过程,我觉得下场会很惨。

我在网上见到一个比较好的例子来阐述type与oop的矛盾:如ForumMessage是一个模型,但是实际中帖子分两种性质:主题贴(第一个根贴)和回帖(回以前帖子的帖子),这里有一个朴素的解决方案:建立一个ForumMessage,然后在ForumMessage加入isTopic这样判断语句,注意,你这里一个简单属性的判断引入,可能导致你的程序其他地方到处存在if else 的判断。

如果我们改用另外一种分析实现思路,以对象化概念看待,实际中有主题贴和回帖,就是两种对象,但是这两种对象大部分是一致的,因此,我将ForumMessage设为表达主题贴;然后创建一个继承ForumMessage的子类ForumMessageReply作为回帖,这样,我在程序地方,如Service中,我已经确定这个Model是回帖了,我就直接下溯为ForumMessageReply即可,这个有点类似向Collection放入对象和取出时的强制类型转换。通过这个手段我消灭了以后程序中if else的判断语句出现可能。

因为今天想实现一个功能,嵌套了4个if,感觉自己好渣渣,过来聊骚几句。文中有什么不妥的地方,望各位看客大大见谅!

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值