Changing2020-12-28看到这个Setter，有个疑惑。在现在的项目中，service层经常出现各种setter，基本是把所有逻辑都放到service层了。之前网上查询了一些资料，把这种称之为“失血模型”。代码这样写有哪些坏处？在既有的项目中，如果要改变的话，需要从哪里做起呢？作者回复: 后面会有一讲专门讨论这个问题，简言之，就是缺了行为，暴露了细节，解决办法就是，引入行为，封装细节。
共 3 条评论18
escray
2021-01-05前两个专栏都还没有学完的老读者又来了。 两个专栏其实已经听了不止一遍，一直想再认真学习一遍，却没能做到。 结果现在已经脱离了编程一线，转型项目经理了，不过还是希望终有一天可以继续写代码。 写 setter 的原因很有可能是因为那些教程或者代码生成工具，set、get 不亦乐乎。 info、Data、Manager 我之前也常用。 去 InfoQ 看了一下十年前的专栏，摘抄一下要点： 1. 让判断条件做真正的选择 2. 判断条件里面不允许多个条件的组合 3. switch 陷阱 4. 重复，是最为常见的坏味道 5. 大心脏是不受喜欢的（函数应该只做一件事） 6. 代码的声明和使用应尽量接近 7. 工欲善其事，必先利其器（Effective 你的语言） 8. 有时候，没有选择是幸福的（两个字符串类） 9. 不允许出现多层缩进 10. 条件编译里面不允许包含多条执行语句 11. 封装全局变量（封装出个行为来） 12. 尽量编写无状态方法 13. 当容器开始嵌套容器，请考虑封装 14. 使用工厂方法处理多个构造函数作者回复: 多谢你对于我老专栏的总结，欢迎回来！
12
邵俊达2020-12-28期待已久，老师前两个专栏都学完了并且都学了不只一遍，收获良多。继续跟老师学习，打磨写代码的手艺。作者回复: 我们一起加油！
6
李威2021-02-03老师，接手一个买回来的商业产品，做二次开发，里面有大量重复代码，此时需要新增一些功能，给的工期短，简单粗暴的办法是继续复制粘贴，再修改修改就可以上线使用，实际上，我们现在就是这么干的。我想请问的是，针对这种烂代码，要去修改它，是应该坚持边加功能边重构，还是一顿复制粘贴用起来先，后续再重构，还是怎么处理比较好。作者回复: 先确认你们自己的策略是什么，如果是短时间用用，就抛弃，然后自己重写，还是就打算以这个系统为核心一直维护下去，不同的策略方案是不同的。 如果要抛弃，就是另起炉灶，按照好的标准要求新代码；如果是维护，每做一块，就重构一块，并且向负责人说明情况，做好投入技术债的准备。
4
每天晒白牙2020-12-28看看我的代码写的多丑作者回复: 看运气了，哈哈。
4
G小调2020-12-28public void approve(final long bookId) { ... book.approve(); ...} book.approve() 是对setter做了封装吗作者回复: 严格地说，是把对数据的操作封装了。
共 3 条评论3
Seed20092020-12-29我前同事说老师才给他们做过一周的技术指导，对您的技术很膜拜。作者回复: 都不记得我在哪个公司留下过足迹了。😁
2
Hobo2020-12-31老师，如果我需要封装一个方法能够对类的一个字段进行多种状态的更改应该怎么封装比较好？作者回复: 为什么是一个方法而不是多个方法呢？用一个方法的结果就是一个setter的变体。
共 2 条评论1
Ankhetsin2020-12-30一个几百行的长SQL算不算方法过长呢？一个bean有上百个字段光设置属性的值并转json不电网络库的代码肯定不止40行了。这个怎么解决？作者回复: 写出几百行的 SQL，一般都是些存储过程，而存储过程早在很多年前就已经被列到不推荐的做法里了。如果是普通的语句，除非是做某些特殊的统计，一般不建议这么做。 一个 Bean 为什么要有上百个字段呢？以我的经验看，这通常是没有想清楚就把所有的东西都塞进来了。所以，应该做的是，做职责分解，把不同的内容放到不同的接口去。
1
Jxin2020-12-28老粉前来打卡。以上书籍都拜读过。就看郑老师如何讲出花来了～作者回复: 我也努力啊！
1