面向过程设计和面向对象设计的主要区别是：是否在业务逻辑层使用冗长的if else判断。如果你还在大量使用if else，当然，界面表现层除外，即使你使用Java/C#这样完全面向对象的语言，也只能说明你的思维停留在传统的面向过程语言上。

传统思维习惯分析

　　为什么会业务逻辑层使用if else，其实使用者的目的也是为了重用，但是这是面向过程编程的重用，程序员只看到代码重用，因为他看到if else几种情况下大部分代码都是重复的，只有个别不同，因此使用if else可以避免重复代码，并且认为这是模板Template模式。

　　他范的错误是：程序员只从代码运行顺序这个方向来看待它的代码，这种思维类似水管或串行电路，水沿着水管流动（代码运行次序），当遇到几个分管（子管），就分到这几个分管子在流动，这里就相当于碰到代码的if else处了。

　　而使用OO，则首先打破这个代码由上向下顺序等同于运行时的先后循序这个规律，代码结构不由执行循序决定，由什么决定呢？由OO设计；设计模式会取代这些if else，但是最后总是由一个Service等总类按照运行顺序组装这些OO模块，只有一处，这处可包含事务，一般就是Service，EJB中是Session bean。

　　一旦需求变化，我们更多的可能是Service中各个OO模块，甚至是只改动Service中的OO模块执行顺序就能符合需求。

　　这里我们也看到OO分离的思路，将以前过程语言的一个Main函数彻底分解，将运行顺序与代码其他逻辑分离开来，而不是象面向过程那样混乱在一起。所以有人感慨，OO也是要顺序的，这是肯定的，关键是运行顺序要单独分离出来。

　　是否有if else可以看出你有没有将运行顺序分离到家。

设计模式的切入口

　　经常有人反映，设计模式是不错，但是我很难用到，其实如果你使用if else来写代码时（除显示控制以外），就是在写业务逻辑，只不过使用简单的判断语句来作为现实情况的替代者。

　　 还是以大家熟悉的论坛帖子为例子，如ForumMessage是一个模型，但是实际中帖子分两种性质：主题贴（第一个根贴）和回帖（回以前帖子的帖子），这里有一个朴素的解决方案：
建立一个ForumMessage，然后在ForumMessage加入isTopic这样判断语句，注意，你这里一个简单属性的判断引入，可能导致你的程序其他地方到处存在if else 的判断。

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

　　从这里体现了，如果分析方向错误，也会导致误用模式。

　　讨论设计模式举例，不能没有业务上下文场景的案例，否则无法决定是否该用模式，下面举两个对比的例子：

　　第一. 这个帖子中举例的第一个代码案例是没有上下文的，文中只说明有一段代码：

　　这段代码只是纯粹的代码，没有业务功能，所以，在这种情况下，我们就很难确定使用什么模式，就是一定用策略模式等，也逃不过还是使用if else的命运，设计模式不是魔法，不能将一段毫无意义的代码变得简单了，只能将其体现的业务功能更加容易可拓展了。

　　第二.在这个帖子中，作者举了一个PacketParser业务案例，这段代码是体现业务功能的，是一个数据包的分析，作者也比较了各种模式使用的不同，所以我们还是使用动态代理模式或Command模式来消灭那些可能存在的if else

　　由以上两个案例表明：业务逻辑是我们使用设计模式的切入点，而在分解业务逻辑时，我们习惯则可能使用if else来实现，当你有这种企图或者已经实现代码了，那么就应该考虑是否需要重构Refactoring了。

if else替代者

　　那么实战中，哪些设计模式可以替代if else呢？其实GoF设计模式都可以用来替代if else，我们分别描述如下：

AOP或Decorator模式
　　
　　其实使用filter过滤器也可以替代我们业务中的if else，过滤器起到一种过滤和筛选作用，将符合本过滤器条件的对象拦截下来做某件事情，这就是一个过滤器的功能，多个过滤器组合在一起实际就是if else的组合。
　　所以，如果你实在想不出什么办法，可以使用过滤器，将过滤器看成防火墙就比较好理解，当客户端有一个请求时，经过不同性质的防火墙，这个防火墙是拦截端口的；那个防火墙是安全检查拦截等等。过滤器也如同红蓝白各种光滤镜；红色滤镜只能将通过光线中的红色拦截了；蓝色滤镜将光线中的蓝色拦截下来，这实际上是对光线使用if else进行分解。


　　如图，通过一个个条件过滤器我们立体地实现了对信号的分离，如果你使用if else，说明你是将图中的条件1/2/3/4合并在一起，在同一个地方实现条件判断。
　　需要深入了解过滤器的实现细节和微小区别，请参考文章：AOP vs Decorator

OO设计的总结　　

　　还有一种伪模式，虽然使用了状态等模式，但是在模式内部实质还是使用if else或switch进行状态切换或重要条件判断，那么无疑说明还需要进一步努力。更重要的是，不能以模式自居，而且出书示人。

　　真正掌握面向对象这些思想是一件困难的事情，目前有各种属于揪着自己头发向上拔的解说，都是误人子弟的，所以我觉得初学者读Thinking in Java（Java编程思想）是没有用，它试图从语言层次来讲OO编程思想，非常失败，作为语言参考书可以，但是作为Java体现的OO思想的学习资料，就错了。

　　OO编程思想是一种方法论，方法论如果没有应用比较，是无法体会这个方法论的特点的，禅是古代一个方法论，悟禅是靠挑水砍柴这些应用才能体会。

　　那么OO思想靠什么应用能够体会到了？是GoF设计模式，GoF设计模式是等于软件人员的挑水砍柴等基本活，所以，如果一个程序员连基本活都不会，他何以自居OO程序员？从事OO专业设计编程这个工作，如果不掌握设计模式基本功，就象一个做和尚的人不愿意挑水砍柴，他何以立足这个行业？早就被师傅赶下山。

　　最后总结：将if else用在小地方还可以，如简单的数值判断；但是如果按照你的传统习惯思维，在实现业务功能时也使用if else，那么说明你的思维可能需要重塑，你的编程经验越丰富，传统过程思维模式就容易根深蒂固，想靠自己改变很困难；建议接受专业头脑风暴培训。

　　用一句话总结：如果你做了不少系统，很久没有使用if else了，那么说明你可能真正进入OO设计的境地了。（这是本人自己发明的实战性的衡量考核标准）。

相关资料：

面向对象与领域建模

GoF设计模式

软件最大的追求是什么？

数据库时代的终结

在Java Collection Framework中定义的List实现有Vector，ArrayList和LinkedList。这些集合提供了对对象组的索引访问。他们提供了元素的添加与删除支持。然而，它们并没有内置的元素排序支持.

你能够使用java.util.Collections类中的sort()方法对List元素进行排序。你既可以给方法传递一个List对象，也可以传递一个List和一个Comparator。如果列表中的元素全都是相同类型的类，并且这个类实现了Comparable接口，你可以简单的调用Collections.sort()。如果这个类没有实现Comparator，你也可以传递一个Comparator到方法sort()中，进行排序。如果你不想使用缺省的分类顺序进行排序，你同样可以传递一个Comparator到方法sort()中来进行排序。如果列表中的元素并不都是相同类型的类，你在进行排序的时候就不是这样幸运了。除非你编写一个专用的跨类的Comparator。

　　排序的顺序怎么样呢？如果元素是String对象，却省的排序顺序是按照字符编码进行的，基本上是每个字符的ASCII/Unicode值。如果严格的限制在处理英文，却省的排序顺序通常是足够的，因为它首先排A-Z，然后是小写字母a-z。然而如果你处理非英文字，或者你只是想使用不同的排序顺序，这样Collections.sort()就出现了第二种变化。例如，你想使用字符串的反序进行排序。为了实现这个功能，你可以在Collections类中通过reverseOrder()来获取一个反序Comparator。然后，你将反序Comparator传递给sort()方法。换句话说，你作如下工作：

　　如果列表包含项目：Man, man, Woman, 和woman，排序好的列表将是Man, Woman, man, woman。这里没有什么复杂的。需要注意的非常重要的一点是Collections.sort()是进行原位排序。如果你需要保留原序，需要先对原集合进行复制，在排序，就像这样：

　　这里，排好序的列表是：Man, Woman, man, woman，但是原始列表（Man, man, Woman, woman）被保留了。

　　到目前为止，排序是区分大小写的。你如何进行不去分大小写的排序呢？一种实现方式是象这样实现Comparator:

　　你确实不需要手工的创建这个类。而是，你可以是用以存在的Comparator，CASE_INSENSIVTIVE_ORDER，它是在String类中定义的。

　　这种实现方式有一点小小的问题。Sort()算法提供稳定的排序，并保持与原有序列相同的元素。这意味着一个包含两个元素”woman”和”Woman”的列表将有不同的排序，而这种不同是根据两个元素在列表中出现的先后次序决定的。

　　语言的不同又会怎么样呢？java.text包提供了Collector和CollectionKey类来进行区分语言的排序。这里是例子:

　　注意，如果你的文本是本地语言，而不是缺省语言，你需要传递一个本地语种给getInstance()方法，就象:

　　你是在对集合关键字进行排序，而不是实际的字符串。这不仅提供固定的不区分大小写的排序，而且它是跨语种的排序。换句话说，如果你对西班牙文和非西班牙文的混合词进行排序，词ma?ana (tomorrow)将排在mantra的前面。如果你不使用Collector，ma?ana将排在mantra的后面。

　　下面这个程序对一个列表进行不同类型的排序（缺省的、区分大小写的、区分语种的）：

　　如果你的主要问题是顺序访问，可能列表不是你的好的数据结构选择。只要你的集合没有重复，你可以在树（TreeSet）中保存你的元素（提供或不提供Comparator）。这样，元素将总是排序形式的。