java 粒度_java抽象的粒度怎么衡量

展开全部

这是个很实际但很少会被考虑到的问题。

国内绝大多数团队在这种情况会选择花费一至两周32313133353236313431303231363533e59b9ee7ad9431333335346133甚至一个月去开需求讨论会来明确需求，因为PM会要求你给出准确的项目计划，销售会要求你给出具体的功能点或者时间来评估价格，领导会要求你承诺何时能够完成。但是花费一至两周甚至一个月去明确需求往往是徒劳无功的，大部分这种项目最终还是会出来成品的，付出的代价是项目超出预算、加班、延期，后期无限的BUG以及超级困难的扩展和兼容。

无法否认这是国内软件行业的现实，至于原因也很明显：国内码农一大把，软件需求未饱和，企业只关注产品数量，很少关注质量。

扯得有点远了，回到这个问题上：统一过程(UP)定义初始阶段一般只有10%的需求被确定或者被分析，也就是说此时已经可以进行设计了，或者说统一过程提倡尽早地进行设计。那么正如问题中所说的粒度应该怎么权衡呢？

但是可以反问一下自己，为什么要权衡细粒度呢？很明显随着项目的开发，需求被慢慢地发掘出来并被理解，细粒度会不断地增加，在各个阶段权衡细粒度都是没有意义了。

也许这个问题的根本原因是害怕当细粒度不断增加的时候，原来粗细粒度的部分需要进行大量的修改，才能增加新的特性。

因此，避免新增特性会影响原来的内容才是设计的重点。如何通过设计来避免这个问题，各个人有不同的观点，要说明也需要比较大的篇幅，这里只给出一些比较重要的面向对象设计原则：如果你认为一个东西不是普通的一串字符或者一个数字，就为其设计一个类。比如金额，包括数目和币种，可以设计金额类和币种类；比如信用卡号，各个号段具有一定含义，可以设计成信用卡号类。

实现关注分离，即系统的某一部分或者某一层只承担一项工作，这项工作是十分明确的。

在系统的某一内聚部分或者某一层范围内，尽量不要破坏对象封装，也就是避免使用get方法。

设计尽量保持低表示差异，也就是设计灵感来源于现实世界，差异不大。

还有很多设计原则，这里就不一一列出来了，只要遵循面向对象设计原则，可以将新增特性或者是业务逻辑带来的影响缩小到个别类甚至是没有影响，这样就可以无视还没有确认的需求大胆地进行设计了。