说一点在程序中减少判断的做法

我们在架构层面上要尽量减少判断，不要让业余逻辑的变动就去修改代码逻辑那样是很不好的，那样的代码维护性很差，很容易造成使用垃圾代码来维护垃圾以至于做成一个垃圾项目。

在架构层面尽量少去使用判断，应该是想办法在判断之前做处理，而不是逻辑柔到一堆去使用判断，不然添加一个类型就又要重新去

加一个If...，我们可以在判断之前让业务本身把各自需要的逻辑处理好，使用接口，让不同的类型处理去实现这个接口，然后在需要处理

逻辑的时候，让业务相关的类型通过一个反射得到对应的处理类，调用处理方法，也就是让业务本身去标识他需要处理的类或者其他标识，

反而一点就是要在判断之前去处理，这样扩展很方便，不会随着业务逻辑的变化而去不断的对代码填填补补。

举两个简单的栗子：

1：比如我们要自己做一个彩票游戏的网站，彩票的玩法有很多种，比如双色球，11选5，快三，还有各种玩法，不同玩法的中奖算法不一样，一个大

类型又可以分为很多不同的玩法。

当用户投注后，要开奖，我们就有很多种中奖算法，难道我们需要在投注表里边去取出来，然后进去根据类型去判断，首先来写这样判断会很多，

而且如果我加了一种玩法呢？不是又要加一个If,可能你会说不同的彩票投注写入到不同的表中，这种情况我们不讨论，只是用这种例子来说明一下，如何通过设计来减少判断，这是一种方法。

我们可以这样做，在表里边加一个彩票类型，还有子类型，但是这两个类型不是简单的存储一个数字，而是可以表示一个类的字符串，当用户投注的

时候不同的玩法会对应一个字符串这样我们在中奖算法的时候就可以通过这个两个字符串拿去反而，不同的类型就会自动知道用什么类来处理了，根本就不需要判断了。

2：比如我们要做一个消息提醒功能，消息提醒分为很多中类型：比如关注消息，评论消息，多级评论，文章推送，系统消息等等等，点击某些消息我们可以跳转到详细的地址，这种情况有些人也会去判断，根据不同的消息型去判断，比如如果是关注消息怎么跳转，如果是评论消息怎么跳转，如果是文章推送消息怎么跳转，但是这种判断我们无法避免么？其实不是的，我们可以在判断之前处理好，如果数据库我们可以在一个url字段，这个字段就是点击后跳转的地址，我们在向这个消息表添加数据的时候自然而然就可以根据不同的需求处理好了，后面就只需要拿来用就好了。

3:比如共用一个更新页面

好了打了一大堆字，一个图片都没有，随便凑一个

仙女