用类降低业务逻辑复杂度

这是我在编码，重构的循环里发现的一种方法。用来降低业务逻辑代码复杂度。她把我的业务代码，从120行降到了30行+类中的70行。我感觉效果相当不错。

一个业务都包括什么元素？

安全检查：负责检查设计涉及该业务的所有变量的合法性，业务逻辑的参数都是错的或者是非法的，结果就不用谈了。

业务功能：完成该业务需要的功能。比如，接收文件需要：协议解析，数据解密，文件保存，数据库记录等等，当然，数据解密仍然可以根据解密算法在划分。

业务功能支持：这部分是独立的可重用的代码，他本身可能与这部分业务逻辑没什么直接关系，但是它确实业务功能需要的。比如，某中字符串处理功能。

现在来看，OO（面向对象）和OP（面向过程）两种方式的相同点和不同点。

相同点：

1.都有元素相同（上面描述的）

2.都要有业务功能函数，即把业务所需要的功能封装成函数

3.都要有底层功能支持库

不同点：

1.对于安全检查，面向过程则一堆的if语句。当然，可以把业务参数封装成一个结构，或者一个类，作为参数传递给一个封装好的函数。然后函数返回安检状态，以及相关原因（即当安检不通过时，返回false并给出错误原因）。但是这么做始终感觉离散度高了点。而对于面向对象来说，可以把安检放入构造函数中，构造函数是不能返回值得，因此我们在类中设置2个变量，一个状态（bool类型bOk），一个错误字符串（string类型strErrorText）。这事候，其实泪构造函数有了两种任务：第一个时期本身，对于对象构造或者说初始化的任务；第二个是，安检任务。我的做法是，对于先进行外部参数安检，如果外部参数非法时，完全没有必要初始化类自身的资源，因为这纯粹是浪费内存和
CPU。

2.对于业务功能，面向过程会封装成一个函数，和安全检查函数放在一个程序文件里，供调用。但是他仍要返回错误和错误原因。那么显然，在面向过程代码里，我们又得去多增加变量，或者说，业务代码中就得有错误处理的if和相关变量代码。而面向对象，则在对象功能返回false时，直接引用对象内部的错误消息串即可。类中需要把该类函数设置为public

3.业务功能，这部分代码，面向过程版本中，我会建立一个lib目录，将它放入其中，公共用。面向对象版本中，我会想将它以private方式放入类中，在我认为他需要公用之后，在移动到lib公共库里面。

结论：

面向对象代码和变量高度聚合，输入参数安检在构造阶段完成，如果参数不合法，对象则不需要再构造。这表现在业务逻辑里面，只需要2-3行代码。业务功能函数，则与初始化，共用错误处理代码。明显，代码量会有所下降，而业务会更加清晰。除此之外，还有一个好处，就是，类中很容易写一个debug类，用来输出当前对象所有属性，方便调试。