方法封装经验

在开发业务逻辑时，当遇到复杂的业务场景时，设计模式可以解决一定问题，但是具体的方法封装还是需要编码来解决，在我看到的场景里，很多人使用了设计模式之后，导致整个代码更加难以维护，代码可读性变得更差，因为他们都是为了练手而使用设计模式，并不是出于这里的确需要一个设计的目的。

方法封装

方法多了以后，会变得混乱不堪，解决的方法有一下几点：
1、将方法的上下层次结构整理清楚，尽量不要形成网状调用关系，要线性关系。
2、方法的入参设计直接决定了方法可复用的程度，进而决定整个调用关系复杂程度，对外接口入参，和内部方法传参一定要分离，不要很多不同方法使用同一个大参数对象，这将会直接导致方法难以使用，逼迫他们新建方法，拷贝逻辑。
3、内部方法尽量使用3个以内参数，能用基本类型就用基本类型，这样可以很方便的被调用。
4、流程很长时，不要用链式调用方式完成逻辑，如a()->b()->c()->d()，而是要a();b();c();d();并列方式完成流程。
5、方法的命名一定要准确，一个命名很差的方法是无法被人理解和调用的，如果你写的方法需要看逻辑才能理解他的作用，那么这个方法的命名就是一个失败的命名。