学习重构的一些思考

关于散弹式修改 

修改一个地方，引发了不少地方都要修改。

举例1：

我在代录页面添加了一列，而后清空列的功能就收到了影响。添加的一列值不能被清空掉。

1： xml里面要多返回一列

2： grid初始化里面要新加入一列

3： grid赋值和取值的地方进行了修改

4： 清空的地方进行了修改

分析：若是要修改一个地方，而且这个地方可能会引发其余的行为修改，那么这些行为应该定义在一个地方，修改起来比较方便。好比，将这些变化的地方作成一个对象类，每次只修改这个对象类。

每一列的相关属性和方法，应该定义在一个类中，这里就是Field类。每次只要修改Field类就行了。

举例2

每个月付记的条目我进行了修改，代录第一页的标签和文本切换和清空按钮收到了影响。

分析：获取每个月复记的条目的逻辑是公用逻辑，可是写在了多个地方，长度也是写死的，而且也写在了多个地方。 程序的公用入口应该只有一个。

好比常量，也应该定义在一个地方。

 

幼稚的数据类

数据类的产生缘由：

受hibernate等框架的影响，java框架中对get和set的应用不少

受到隐藏做用域思想的影响

有的类中某个函数要完成处理，须要的参数有不少，就作了这种数据类

数据类的缺点

未理解面向对象的设计方法

增长了类的数量

举例1

公用导出中，根据action导出文件的模块。

我首先根据前台js传递来的导出参数，映射成后台的属性，因而我新建了一个类，并生成了get set方法。这个类后来只用来进行了存储数据的功能。

根据这些参数造成文件的逻辑，应该都放到这个类中来。

 

将数据类有关的行为转义到数据类中对我来讲，无疑是一个观念上的转变。

 

关于为何要重构，个人想法

在平时的开发中，不多有能进行重构的场合。开发人员对重构的认识有限，没有认识到重构带来的好处。时间紧迫，写代码加测试模式的超级敏捷开发流程是大流

咱们不得不在不少状况下维护某些代码，这些代码不得不被修改。这些代码咱们不容易看懂，看懂了发现修改一个地方会引发不少地方要进行修改，须要变化的地方多是分散在软件的各个角落，每错过一个地方，均可能会引发严重的问题，致使返工。

而后咱们就想，为何当时设计程序时候没有更好的设计呢？为何没有把变化的东西封装到一个类中呢？ 由于各类缘由，开发时候的确作不到这点，那维护的过程当中咱们是有精力去作这件事情的，重构了这些代码，能更便于咱们往后维护。咱们也知道之后将怎么提升咱们软件的可读性和可维护性。

 

有些类只有方法的思考

有一个类，类中有一些方法，类没有什么字段，方法很长，方法中有不少参数，能够将这个方法作成一个对象。

这样一来，有一种观念的改变，你不是总在定义方法，你定义了对象。

函数是能够转化为对象的，避免函数参数过长 这也是个思想上的改变

 

关于算法的思考

我开发记帐易软件时候，作一个用户选择记帐方式的页面，我有一个逻辑，后来出现了不少问题，我发现我把问题想的很复杂，可是以为这东西应该没有这么复杂，后来换掉算法后，发现清晰了不少，BUG也少了不少。

像EXCEL的合并算法，拐角现算法都有优化的控件

若是一个类的功能不多，那就应该把这个类的功能转义到其余函数中，这样就能少维护一些类。

单向关联与双向关联

定义常量  避免常量的值分散在类的各个角落。若是你引用的值能够经过其余的入口得到，请修改为统一入口，避免修改多个地方。

 

关于异常

非受控异常 程序员犯的错误  不能够被捕捉处理，程序强制终止，调用的时候应该检查的可是没有检查。

受控异常  调用的时候，调用者没有检查，检查的责任在咱们负责的部分，咱们应该抛出一个异常，这个异常是能够被调用者捕捉的，而且调用者能够选择发生异常的时候应该怎么作。

当接口发生改变的收，接口的结构最好不要发生改变，由于调用的地方可能会不少。好比加上了抛出异常处理。

受控不受控这个东西，对我是个新知识。