过长参数列
太长的参数列难以理解，太多的参数会造成前后不一致、不容易使用，而且一旦你需要更多数据，就不得不修改它。如果将对象传递给函数，大多数修改都将没有必要。
发散式变化
如果某个类经常因为不同的原因在不同的方向上发生变化，那么此时也许将这个对象分成两个会更好，这么一来每个对象就可以只因为一种变化而需要修改。
散弹式修改
如果没遇到某种变化，你都必须在许多不同的类内做出许多小修改，你所面临的坏味道就是散弹式修改。如果需要修改的代码散布四处，你不但很难找到它们，也很容易忘记某个重要的修改。
把所有需要修改的代码放进同一个类中，如果眼下没有合适的类可以安置这些代码就创造一个。
依恋情结
对象技术的要点在于：将数据和对数据的操作行为包装在一起（充血模型的思想）
有一种经典的气味是：函数对某个类的兴趣高过对自己所处类的兴趣。某个函数为了计算某个值，从另一个对象那调用几乎半打的取值函数。
一个函数往往会用到几个类的功能，那么它该置于何处？我们的原则是：判断哪个类拥有最大被此函数使用的数据，然后就把这个函数和那些数据放在一起。
数据泥团
很多地方看到相同的三四项数据一起出现。这些总是绑在一起出现的数据应该拥有属于他们自己的对象。
首先找到这些数据以字段形式出现的地方，将它们提炼到一个独立的对象中。这么做的直接好处是可以将很多参数列缩短简化函数调用。
比如：商品名称，商品价格，商品种类，商品重量…总是一起出现，于是我包装了一个商品类
但是实际开发中，可能看起来并没关系的几个属性，也总是一起出现，那也可以包一个类。
但是实际并不建议这样做，因为目前主流的设计思想是领域驱动设计，它认为，客观现实所存在的东西，才能抽象成数据模型。
基本类型偏执
对象的一个极大价值在于：它们模糊了横旦与基本数据和体积较大的类之间的界限
对象技术的新手通常不愿意在小任务上运用小对象——结合数值和比重的money类、有一个起始值和一个结束值组成的range类。将原本单独存在的数值替换成对象，从而走出传统的洞窟，进入炙手可热的对象世界。
switch惊悚现身
面向对象的一个最明显的特征是：少用switch语句
一看到switch语句，就应该考虑以多态来替换它。
如果只是在单一函数中有些选择实例，且并不想改动它们，那么多态就有点杀鸡用牛刀了。
平行集成体系
每当你为某个类增加一个子类，必须也为另一个类相应增加一个子类。
消除这种重复性的一般策略是：让一个继承体系的实例引用另一个继承体系的实例。
冗余类
某个类原本对得起自己的身价，但重构使它身形缩水，不再做那么多工作，这个时候请让这个类庄严赴义吧。
标签：重构,函数,对象,代码,之道,修改,一个,某个,数据 来源： https://blog.csdn.net/GBS20200720/article/details/122767134
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。