亲们，我问个令我纠结的问题
 


  有个逻辑层service。service层里包括了几个方法，我的任务是吧这几个方法分别写道几个service里，也就是一个

service里负责一个方法。我想问问，这么写确实是可以比一个service里写几个方法那样的提高效率吗？为什么呢？


  以前是一个service里有三个方法，现在就是吧三个功能分成三个service。

------解决方案--------------------
一般情况，明显不会提高效率，原因很简单，在相对条件相同的情况下，三个service至少要创建三个实例，


这样做的好处，可能是为了代码结构上的清晰，
------解决方案--------------------
如果几个方法没有关系，分开写结构清晰，如果有关系，还是放到一起好。
------解决方案--------------------
也这是我想说的，这样做更便于以后的升级维护，要改动的地方小。

探讨

一般情况，明显不会提高效率，原因很简单，在相对条件相同的情况下，三个service至少要创建三个实例，


这样做的好处，可能是为了代码结构上的清晰，

------解决方案--------------------
效率本身往往不是最关注的，除非某些极限情况。

项目开发一般更看重：结构清晰、可读性好，这样可以保证组内写作和后续长期维护的综合性价比最高。


不过很多事情不绝对，你可能觉得这个Service总共也就 20行代码，还切成3个类，不是多此一举？
有时候确实是这样，但是主观判断自由度太高，难以规范化管控，所以一刀切的管理方式会更常用，简单点说就是：
Rule is rule.
------解决方案--------------------
如果你们的客户是BT的话，或者说你们项目是长期项目的话，尽量写开吧，这样易于扩展延伸。也易于维护之类的。

如果是个矮项目那就写一起算了。

效率之类的词，听起来多玄乎，其实就那么回事。所以说LZ别纠结了。根据实际项目来吧。