Java 谈谈你对OOA、OOD、OOP的理解 二

OOA（面向对象分析）、OOD（面向对象设计）、OOP（面向对象编程），这3个概念，对于我们JAVA程序员来讲，或多或少应该都有所了解，或者说至少都听说过。

但是要谈到对其理解，可能对于多数入行不深的从业者来说，确实不是那么容易做到。特别是对于绝大多数的3年以内的低中级软件工程师而言。

因为他们的工作更多是需要按照项目经理分配的任务来编写功能代码，很少有多余的时间去阅读或者思考一些概念性的东西。说起这个问题，我也在网络上也搜索过很多的资料，大多都是摘录至书籍，比较官方化，让初学者无从理解。

昨天给大家分享了对于分析业务流程，常见的2种：面向过程分析（POA），面向对象分析（OOA）。今天干货继续：

在JAVAEE项目中，组织业务逻辑的方式：事务脚本（面向过程设计 POD）、领域模型（面向对象设计 OOD）

事务脚本（面向过程设计 POD）：它是纯面向过程的一种组织业务逻辑的方式，在JAVAEE项目，是一种非常常见的设计方式，做法很简单，将POA分析后的结果封装成JAVA对应的方法即可，然后在业务层中统一按照顺序调用接口。将领域对象（人民币）去掉行为，只保留属性即可，用于数据传输。以数据流向为主要导向。

按照上述的业务场景来设计：保留失去行为的领域对象（人民币），同时抽离出一个业务层的接口类，多个持久层的数据访问接口类，在业务层接口中提供一个统一的业务调用方法transferAccount(),在数据库发生关系的持久层，提供一系列事件方法：queryBalance(),reduceBalance(),increaseBalance();使用UML类图表示为：

当然还有一系列的表示手段，比如：包图，对象图，序列图，用例图…… 这里就不一一设计了。

领域模型（面向对象设计 OOD）（Object Oriented Design）：主要是正确有效的构造出复杂系统的抽象结构，将面向对象分析后的结果，作为面向对象设计的模型，通常用于展示被设计系统的逻辑模型（业务逻辑如何设计），物理模型（系统如何划分，层次如何划分，如何部署……），静态模型（组成系统的元素：类，接口）和动态模型（对象的调用……）。将OOA分析的结果作进一步的规范化整理，以便能够被OOP直接接受。

概念可能比较生硬，那么说的直白点，设计阶段的任务就是：

需要注意的是：层次结构并非就一定是三层结构，也可以是多层，具体分几层需要根据项目的复杂度来决定，如果没有过多的业务逻辑，只有简单的CRUD的话，那么三层结构足以应付一切。

按照上述的业务场景来设计：

对于领域逻辑来说，三层结构就不能满足其业务逻辑复杂度了，可能这时整个系统可能是四层，五层，或者多层……，我们这个例子，暂时定为四层结构：控制层、业务层、领域逻辑层、数据访问层。在设计领域对象时，保留失去行为的领域对象（人民币），转钱对象，收钱对象，同时抽象出一个业务层的业务接口用于简单的调度业务逻辑，多个持久层的数据访问接口类。

在OOA阶段，我们分析出张三这个实例，可以查询自己卡中余额，可以从余额中取出5000元，也可以将外来的钱加入到自己的账户中。那么它就应该对应着对应的3种行为方法。

李四这个实例，可以查询自己卡中余额，可以将外来的钱加入到自己的账户中，那么它就应该对应着对应的2种行为方法。而5000元人民币只是数据的传输携带者，没有任何行为可言

如果采用UML中类图的表示法来看，图形应该如下：

（在同一个图中，相同名称的元素代表同一元素）

在这张图中，我们的层次就是4层结构，甚至我们还可以再分为5层，6层等，所以一般领域模型适用于业务需求较为复杂的情况。业务层仅仅是为了梳理业务流程，而真正的业务逻辑则交由领域层的领域对象之间相互调用对方的方法来实现业务逻辑。比如要转钱，就需要转钱者领域对象，减少自己的余额后，调用收钱者领域对象，添加自己的余额。当然真正的银行转钱复杂度，绝对远高于这个场景。 还需要使用到事件驱动模型，以及消息队列等一系列的技术，当然具体情况具体分析。

面向对象编程（OOP）

面向对象编程（Object Oriented programming）：将面向对象设计后的抽象，采用面向对象的方式来实现的方法，就叫做面向对象编程。在这种方法中，程序被组织成许多相互协作的对象，每个对象都是一个类的实例。利用对象构成业务逻辑的组成基本元素（组合模式的层次结构），而不是采用算法。组成程序的基本元素是一个又一个的基础组件（类），那么组件就是我们层次结构所对应的接口或接口的实现类，那么程序就是由一个又一个实现类的实例相互协作来完成业务逻辑的实现。

总体来说：面向对象分析的结果可以作为面向对象设计的模型，而面向对象设计的结果则可以作为面向对象编程的蓝图，应用程序需要由编程才能实现。

End