技术一般 不会贴图 原谅!!!
怎样做好软件开发过程中的模块化是一个值得思考的问题。
在思考这个问题之前，我曾做了当前工作中的项目代码部分重构，我自己给自己定的重构原则是，按照职责单一来划分模块。在函数拆分中将功能能构独立出来的代码行拆分成一个函数封装成一个接口。
在没有见到上图之前，我没有觉得自己哪里不对，但是上图引发了我的一个思考，我的拆分原则有没有问题，按照书面知识看似毫无破绽，面向对象的设计原则其中一条讲的就是单一职责原则。但是事务总是在带来好处的地方也带来负面效应，过度的拆分导致模块调用的过程中接口增多。接口成本也随之增加。这是一个问题，那么我们到底该如何进行模块拆分。
又是一些没有营养的建议，我恶心下自己：
1 拆分原则，还是按照书本上的知识--单一职责原则。
2 具体实施，根据业务场景进行功能的划分与合并，然后进行拆分。
3 一些业务无关的工具模块拆分越细越好，这些东西积累起来就是财富，越细越容易被重复使用。
。。。后续想到补充
扫一扫
1626
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
