面向对象

如下文章纯粹是本身的观点与对于面向对象的理解，有不妥之处，望指出！

初次读完设计模式以后，感受没什么用处，鉴于当时本身仍是初级开发，因此理解的不够深入；可是，如今深入的理解，设计模式必须得读，他直接影响的是你的编程思想。

成天说面向对象面向对象，可是大多数状况下咱们只是用面向对象的语言写出面向过程的代码。咱们一般都是在一个类中写了不少个方法，而后方法按照通常面向过程的思惟实现需求要咱们实现的功能。长此以往，你会发现，写代码真没没劲，来回是那几行，这时候你须要读读设计模式，让本身的代码更美观，提升本身系统的可扩展性、可重用性、可维护性。

很少说，拿实例说话。

最近在开发一个关于练习的系统，学生进到系统能够根据本身的学习状况练习。

咱们只拿出一个系统的核心模块，加载练习来讲。

     这个模块的需求是这样的，学生会根据本身的学习状况选择不一样的答卷模式，目前咱们系统分为了3种：简单、通常、困难；加载这三种类型的试卷的试题时，会根据学生的练习状况、答题状况动态的去根据不一样的算法加载。好吧，需求说道这里，下面咱们来讲实现。

     通常咱们会建一个Service，这个Service只是提供加载练习的服务，里面可能会有3个方法，加载简单试卷、加载通常试卷、加载困难试卷；

      当咱们在写加载试卷的方法的时候，可能会先获得学生的练习状况，再获得学生的答题状况，再根据这些内容去库里找到对应难度的试题。当咱们须要查找数据库时，可能会调用Dal层的增删改查的方法。完了以后会把以上所作的操做拼接成一个流程，最后会获得一些试题列表返回到前台。

      那么问题来了，若是咱们又增长了一种难度的试卷，是否是咱们会再写个方法，再操做一遍以上的内容，再整合成一个流程......

      你可能会说，这中间不少方法，均可以公用啊，好吧，若是当我获取简单试卷的方法时获取答题状况的算法改了，那么是否是至关于整个获取试卷的Service都改了，由于咱们修改的是公用的核心方法。

    针对以上问题，咱们首先应该想到设计模式，设计模式的目标就是提升系统的可扩展性、可重用性、可维护性。

    分析后你会发现，其实获取试卷的流程同样，不同的只是算法而已，那么咱们能够抽象这个算法为一个接口，不一样的试卷算法继承自这个接口，这样咱们修改某个算法时，不会影响到其余的算法。UML以下

那么，不论获取什么试卷，流程是同样的，咱们就能够把这些流程封装成一个接口，咱们只要获取试卷，调用这个接口便可，不一样的是上面说的算法不一样而已，咱们就又出来一个接口：

这样咱们就解决了上面遇到的问题。

综上，本篇文章只是一个例子，旨在引导你们拿到需求先分析，运用面向对象的思想来完成咱们的需求。