在编写java代码时
今天说下，在编写java代码时，大家对于公共方法的修改，是如何做的。
在java中，公共方法包括两种，一种是工具类的代码，比如日期工具类，文件工具类等等。这种公共方法，一旦写好，极少会有修改的可能，所以这种情况我们不做讨论。还有一种是业务类的公共方法，因为业务会经常变化，所以可能会导致公共方法也会经常变化，今天主要说下这种情况。
假如有一处公共方法，被10处业务场景所调用，如果场景1业务需求变了，需要修改公共方法，该怎么改呢？
有人可能直接在公共方法里判断，如果是场景
1，则走新逻辑，否则走原逻辑，如图一所示。但是这样改了，以后如果有其他的场景的业务需求也变了，你又需要在公共方法中添加判断，这样就会使代码特别的臃肿复杂，而且容易影响其他业务，所以这种方案是不可取的。
有人可能直接放弃调用此公共方法，重新写一个新的方法去调用，但是这样的话，如果原公共方法的逻辑比较多，而你只需要修改其中一小处逻辑，其他逻辑不变，那你重新写一个方法，就会造成大量的重复代码，无法做代码复用，所以这种方式也是不可取的。
我通常都是怎么做的呢？首先，我在第一次编写这个公共方法的代码时，就会对方法中的逻辑做拆解，拆解成n个小方法，使每个小方法都无法在继续拆解，然后将每个小方法的访问至少设置为protected，保证子类可以重写，然后在入口的大方法里，把n个小方法组合起来，如图二所示。然后比如场景1的业务发生了变化，就新建一个子类去继承原来的公共方法类，去重写需要变化的小方法即可，如图三所示，这样既可以不修改原有代码，也可以复用原有代码。当然，这样做也是有缺点的，如果业务场景变化的多了，会是继承关系变的很复杂，当然了，可以用一些设计模式来优化一下复杂的继承关系，比如说装饰者模式，但是我觉得没啥必要，因为这个继承关系一旦变的很复杂了以后，就说明你这个公共方法，已经无法满足多种业务场景去用了，这时候就需要去考虑做代码重构了，而不是去考虑优化继承关系了。
大家有什么不同看法吗？欢迎评论区留言讨论
