漫淡面向对象——POJO对象

产品或者服务由数据存储和数据计算组成。pojo对象就是用于数据存储。一旦肯定后，整个应用或者产品的数据来源就肯定。好比一个页面或者功能须要使用什么数据就能够快速找到对应的对象或者经过对象的关系找出来。

pojo对象属于对系统的静态描述。它应该是名词，不该该是动词或者其余。动词、类型或者状态等应该是算法类型的对象，权限应该是AOP考虑的，在后面的漫谈里还会详细提到。

目的

对领域的客观描述反应。好比说：教育领域，农业领域，电商领域，零食领域等。这些只要领域背景没有变化，就会是客观稳定的。固然不一样的产品的商业模式对同一个领域的理解也会不一样，这些是会常常变化的，可是一般也只是体如今流程、类型、算法、功能等上面，这些并不影响pojo对象。

• 全部人在沟通的时候理解一致
• 每一个对象职责单1、明确、不可替代

属性分类

为了快速区分属性，而且快速找到真正的pojo对象和属性。这些属性能够在产品里的新增、详情、列表等功能里获得体现。

自描述

通常体现出来的就是手动输入。好比：名称，标题等。

关联

有依赖来源，即在别的地方是手动输入，可是当前功能是选择。好比：选择地区，选择类型。

冗余

方便查询，减小复杂度。通常有如下状况：

• 一旦生成不会变化的，能够考虑冗余，由于这样能够减小复杂度。
• 偏统计类。好比：视频里冗余评论数购买数。
• 为了减小不一样类型表的依赖。

功能

个性化业务，纯粹是为了作功能

只留自描述，这个很难。须要深层次了解领域。经过领域驱动设计。这样能够经过面向对象，经过不多的关注点，对整个系统有个静态的认识。并且还能够判断出产品变动的时候对整个系统的结构（即数据存储）有什么影响。特别是出现新名词的时候。

须要根据产品的实际状况来判断这些属性怎么规划。若是是想要快速、简单，可是4种类型都放到pojo上，开发是最快的，可是同时确定也是扩展性最差的。也须要根据产品的真实需求来判断怎么处理后面3种类型的属性。

抽取步骤

不少童鞋打着面向对象的幌子干着面向过程的事。在抽取名词的时候同时又考虑算法、流程、权限等。这样一来关注点几何倍数增加，原本应该用于考虑pojo对象是否合理的时间更没办法充分获得利用。

不少童鞋想成一次就把对象抽取出来。实现上抽取比印象中还要复杂。因此建议的是分步骤，循序渐进的去抽取才是最快的办法。

枚举

只是把产品里涉及到的全部名词枚举出来。
下面是枚举时的陷阱：

• 不要去经过本身的理解去修更名词叫法
• 不要去忽略本身以为不重要的名词
• 不要考虑表怎么存储
• 不要考虑非名词

这些陷阱很容易让后期返工。

删除

删除和产品（领域）无关的名词。好比：文案可能出现了故宫或者平台名等和本领域无关的名词。

去重

必需确保每一个名词都是职责单一，不可替代的。
通常去重的特征以下：不一样的名词体现出来的属性，功能和生命周期是同样的，只是描述不一样。
好比： 不一样角色的人在对同一个名词描述不一样，他们在新增的时候属性类似度很是高，流程也特别像。

通常的反问本身或者产品：

• 它们的不一样点在哪？
• 若是改一个地方，另外一个地方会不会须要同时修改？
• 若是把它们作成同样会有什么问题吗？

添加

• 在描述一个概念的时候，必须经过很是多其余对象，并且常常提。
• 虽然产品没有提过，可是在实施的时候发生有不少对象有同样的特性。常见状况：
  • 一个列表涉及到很是多的名词，可是列表自己产品并无体现概念。
  • 不一样的名词，他们的属性很雷同，并且生命周期几乎是同样的，有种几条平行线的感受。好比说：一样要新增、发布、审核等

聚合

把属性名词聚合到对象名词里。这里务必确认只放自描述属性。其余的属性暂时不考虑，由于能够很方便的经过关系来描述，并且这个也常常会变化。

陷阱

若是有如下的状况说明对象分析的不够合理，后面很容易返工，请务必重视。

单方面描述

有一方有一直在说，可是另外一方历来不提。说明这里缺乏重要名词。

描述不一致

在描述同一名词的时候，每每需求进一步翻译。
这样可能会出现的问题是：

• 沟通和维护成本增长
• 极可能缺乏重要信息或者说关系理解的不对等。

组合描述

• 用多个词来描述一个概念。须要一个新词。
• 一个概念没有具体自描述，而是关系出来的，可是又是沟通描述时常常出现。

推荐书单

• 《UML基础，应用与案例》
• 《领域驱动设计》