《代码整洁之道-第十章 类》读后感

《代码整洁之道-第十章 类》读后感

前言:
通篇仿佛再告诉我，不要怕代码量大，不要怕文件多。我之前可能追求的是什么，通用性，减少我认为的很多不必要的代码，降低代码量，将尽量多的功能融合在一起，比如:修改的函数会和创造的函数合并，无即创造，有则修改等。对于这方面，我以后应该会去降低通用性，而尽量保持功能简单。
高内聚低耦合，单一权责类这些是一直知道的，但可能由于lua太过于方便，渐渐的失去对这些的把握，但后续也视情况而定吧，毕竟我们的项目不是一个长期迭代升级的项目（现在的S级项目可能算是吧），太多小类，太影响感觉了。

1.类应该短小，保持单一权责
尽管我知道，他是对的，他也拿出很多理由说服我，但cocos可以在代码直接创建节点的方式，真的很难让我放弃他的便利性，而去建多个类来保持单一权责，后续unity的一个每个功能节点，绑定一个脚本，再试着修改吧。
避免小技巧：1.类的行数，这个我们检查代码中，也有在过滤超过800行，就是说明这个类，太负重了。2.类名单词数，类名越长就可能代表他权责越多.3.函数量，函数量越多,也可能代表功能太杂，比如大部分人的tools类，但渐渐我发现，大家也都意识到了，以前动作，引导，数据处理等都放在tools，现在渐渐也分出来了。

2.保持内聚
lua没有私有性，导致我存在不同类之间，相互调成员变量，接下来的话，A->a，A->b，这样的关系的话，a和b之间应该保持不相互调成员变量，而是利用A进行传递，减少耦合性。
避免小技巧：成员变量太多，毕竟不用大部分函数，都使用这些变量，很多可能可以单独分出去。

3.为了修改而组织
开发完之后，必定会有大量的修改，这时候经常会遇到公共类的子类特殊化处理，就应该隔离修改，保持公共性，又特殊性（重写功能函数，会降低公共性，如果不是太特殊，子类尽量不要重写公共类的功能函数）。
其他语言怎么实现隔离修改，是写个接口函数，lua没有接口怎么办，在公共类写个空函数，子类重写空函数内容来，实现特性。
避免小技巧：这个就是注意下，避免重写公共类的功能函数，不然容易出现公共类修改，后面子类没有修改的情况，导致排查困难。

总结：
1.第一点类需要短小，第二点类需要更短小。
2.单一权责原则：类或模块应有且只有一条加以修改的理由。系统应该有许多短小的类而不是巨大的类组成。
3.内聚：如果一个类中的每个变量都被每个方法所使用，则该类具有最大的内聚性。内聚性高，意味着类中的方法和变量相互依赖，相互结合成一个逻辑整体。
4.为了修改而组织。类应当对扩展开放，对修改封闭。我们可以借助接口和抽象类来隔离这些细节带来的影响。（lua借助重写公共类的预留下空函数）

最后，笔者表示，上述总结，只是读后感，非常认可这些观点，但自己并不会完全去遵守上述的全部规则，需要视情况而定，当然可能是目前目光短浅。 2021- 11 -11