这种现象在所有的面向对象工程中都会遇到，在我们编码时，对一般的对象比如mvc的，我们可以把写好的类文件放到相应的model view controller包里面去。但是对于一些共用类就不那么好处理了，比如一些工具类，或者是共用对象，你对它一个类命名一个软件包吧好像有点浪费，但是他们之间又确实没啥关联。很常用的做法是全部放到一个类似util的包里，但是最近看到一篇文章说这样过于简单粗暴，而且其他人也不好理解这样的分层，不知道各位是怎么处理这个问题的。
2 回答
慕斯709654
TA贡献1840条经验 获得超5个赞
对于这种问题，没有什么硬性规定，重要的是团队内部必须形成规范，且团队的每个成员必须遵守这个规范，这样的话，就会降低新加入成员的熟悉成本。
我们团队内部对于项目公用的一些工具类(类似StringUtils,CollectionUtils等)，也会以Util打成包；对于一些模块内部的共用对象，如果是一些enum类，则会以enums打成包；如果是一些模块(例如module1等)内部层与层之间的对象，则会先以dto命名包，再将其放入用其模块名命名的子包内，对于一些模块之间共用的对象，放入common命名的子包，其他共用的类，也会类似的先按照业务功能命名包名，然后在包内，按照不同模块划分子包。
最后一点重要的还是形成并遵守规范。
白衣染霜花
TA贡献1796条经验 获得超10个赞
这就是我不提倡纯面向对象的原因之一, 很多时候可以作为一个函数的东东, 一定要被包装成一个类, 加上一个命名空间, 写成一个静态方法.
如果用一个比较好的语言系统, 应该首先语言标准库就提供很多重要的函数和类
其次是第三方库, 作为vendor
然后是本身有价值的东西, 可以有common, 或者内部开源成为一个第三方库, 规范接口.
我不提倡在一个公司的几个projects之间share common, 否则其他团队的修改会bug/crash你的产品, 不如将原来的common fork出来加以修改.
最后是和这个项目的直接相关的代码逻辑
团队沟通是成本最高的, 唯一的办法, 控制开发团队人数
添加回答
举报
0/150
提交
取消