以下文章纯粹是自己的观点与对于面向对象的理解，有不妥之处，望指出！
初次读完设计模式之后，感觉没什么用处，鉴于当时自己还是初级开发，所以理解的不够深刻；但是，现在深刻的理解，设计模式必须得读，他直接影响的是你的编程思想。
整天说面向对象面向对象，但是大多数情况下我们只是用面向对象的语言写出面向过程的代码。我们通常都是在一个类中写了很多个方法，然后方法按照一般面向过程的思维实现需求要我们实现的功能。久而久之，你会发现，写代码真没没劲，来回是那几行，这时候你需要读读设计模式，让自己的代码更美观，提高自己系统的可扩展性、可重用性、可维护性。
不多说，拿实例说话。
最近在开发一个关于练习的系统，学生进到系统可以根据自己的学习情况练习。
我们只拿出一个系统的核心模块，加载练习来说。
这个模块的需求是这样的，学生会根据自己的学习情况选择不同的答卷模式，目前我们系统分为了3种：简单、一般、困难；加载这三种类型的试卷的试题时，会根据学生的练习情况、答题情况动态的去根据不同的算法加载。好吧，需求说道这里，下面我们来说实现。
一般我们会建一个Service，这个Service只是提供加载练习的服务，里面可能会有3个方法，加载简单试卷、加载一般试卷、加载困难试卷；
当我们在写加载试卷的方法的时候，可能会先得到学生的练习情况，再得到学生的答题情况，再根据这些内容去库里找到对应难度的试题。当我们需要查找数据库时，可能会调用Dal层的增删改查的方法。完了之后会把以上所做的操作拼接成一个流程，最后会得到一些试题列表返回到前台。
那么问题来了，如果我们又增加了一种难度的试卷，是不是我们会再写个方法，再操作一遍以上的内容，再整合成一个流程......
你可能会说，这中间很多方法，都可以公用啊，好吧，如果当我获取简单试卷的方法时获取答题情况的算法改了，那么是不是相当于整个获取试卷的Service都改了，因为我们修改的是公用的核心方法。
针对以上问题，我们首先应该想到设计模式，设计模式的目标就是提高系统的可扩展性、可重用性、可维护性。
分析后你会发现，其实获取试卷的流程一样，不一样的只是算法而已，那么我们可以抽象这个算法为一个接口，不同的试卷算法继承自这个接口，这样我们修改某个算法时，不会影响到其他的算法。UML如下
那么，不论获取什么试卷，流程是一样的，我们就可以把这些流程封装成一个接口，我们只要获取试卷，调用这个接口即可，不同的是上面说的算法不同而已，我们就又出来一个接口：
这样我们就解决了上面遇到的问题。
综上，本篇文章只是一个例子，旨在引导大家拿到需求先分析，运用面向对象的思想来完成我们的需求。