忌过程耦合，忌封装性差，
三个原则，一是封装，二是继承，三是多态
注意保护，类的私有成员变量。
SOLID原则
单一，开闭，里氏替换，接口分离，依赖倒置
私有成员，内部状态
构造注入
属性注入
方法参数注入
属性返回内部状态
方法返回内部状态
类，明确用途
生命周期，何时创建，状态变化，何时销毁
关联哪些资源，资源的状态变化
很难找到修改点，修改就容易引入BUG
单一职责SRP
分解长方法，移至短小方法
switch单独一个方法
提取方法之后，重新命名方法內变量，参数的名字
提取方法之后，观察方法內依赖的对象，方法的意图，思考方法是否仍然属于当前类的职责。
多数情况下，方法依赖什么对象，简单来说，方法的参数，是什么对象，那么方法就应该存在于那个对象所在的类中。
在将方法移动到依赖对象类中后，可能参数不再需要，方法名字继续变化，根据实际进行调整测试通过。
对于循环內多行语句，多个职责，可以考虑提取方法，每个方法都进行循环，执行单个职责。
switch语句不要用在另一个对象的某个属性上，最好在属性自己所在对象上使用switch
方法再次移动到某个类后，可能需要原类属性作为传入参数调整。
始终记住，职责，意图，单一职责，单一意图
我们将方法都归位之后，通俗讲就是，方法足够小，并居住在他应该在的类中。
我们要开始考虑继承了。。。。
通常适合继承的是，类型，有多少种类型呢，换句话说，有多少个子类呢？
有了继承，子类的关系，我们就可以利用多态，替换掉 switch 判断。
多态，往往更能表达灵活清晰的条件逻辑，switch 判断，if else 判断。
重复代码。
相同的程序结构。
同一个类中，两个方法有相同的代码逻辑。
两个类，兄弟子类，含有相同的类似代码逻辑，提取出来，放到父类。这时候，有多个选择，父类一个方法，父类一个默认实现，子类重写，父类做一个模板方法模式，子类重写等。
两个毫不相干的类，出现重复类似代码。提取出来，放在一个新类里面。
方法太长
方法內的相同功能逻辑块，if，switch，while 等，这些都是可以提取为更小方法的信号。
过大的类
参数过多
一个原则，方法的参数，应该大多数可以在其宿主类中获得。
参数实在太多，应该传递对象参数。
代码发散式变化
代码散乱式变化
依恋情节
将数据和对数据的操作行为包装在一起。
有个方法，过多的使用另外一个类数据，方法。此时应该把这个方法移动到那个类。
数据泥团
a字段，b字段总是一起出现，a参数，b参数总是一起出现，
这种情况，就需要为a，b封装一个对象
临时变量，不要重复赋值，重复赋值，说明变量的意图改变，当然除了在循环中。
不要给方法参数赋值。
返回值有多个，的方法，思考分隔为几个小方法，思考返回一个对象。
网友评论