我最近由我公司的一位高级开发人员审核了我的代码.他批评我的设计使用了太多的课程.我很想听听你的反应.
我的任务是创建一个服务,该服务生成一个xml文件,因为它操作了3个其他xml文件.我们将这些命名为aaa.xml,bbb.xml和ccc.xml.该服务分两个阶段进行.在第一阶段,它会针对bbb.xml清理aaa.xml.在第二阶段,它将第一阶段的产品与ccc.xml合并以产生最终结果.
我选择了一个包含三个类的设计:一个XmlService类,它使用了另外两个类,一个scrubber类和一个merger类.我保持擦洗和合并类是分开的,因为这两个类都很大并且具有不同的逻辑.
我认为我的方法很好,因为它让我的课程变得小而有凝聚力.我的方法也有助于控制我的测试类的大小.
高级开发人员断言,清理和合并类只能由XmlService类使用,因此应该是它的一部分.他觉得这会使XMLService具有凝聚力,这就是他所说的具有凝聚力的意思.他还认为以这种方式分手,会使他们松散凝聚力.
具有讽刺意味的是,我试图打破这些课程以达到凝聚力.你怎么看？谁对或错？我们都对吗？谢谢你的建议.
Hum*_*rto 13
如果您遵循单一责任原则(并且基于您的问题的基调,我认为您确实遵循它),那么答案很明确:
这是非常广泛的,而且确实是主观的 - 因此与你的同事的斗争.在你身边,你可以争辩说:
此外,我认为你的老板对凝聚力有误解.将其视为焦点:程序的重点越窄,凝聚力越高.如果卫星类中的代码在服务类中合并,则后者变得不那么集中(不那么有凝聚力).人们普遍认为,较高的内聚力优于较低的内聚力.试着启发他/她对此的看法.