面向对象分析与设计

面向对象分析与设计是指根据面向对象方法学对软件系统进行分析与设计。在面向对象分析与设计的定义中有三个关键词：面向对象、分析、设计。所以，为了更好地理解面向对象分析与设计的作用，我们首先要理解什么是面向对象，以及面向对象分析和面向对象设计的原则。

什么是面向对象

面向对象是对现实世界进行理解和抽象的方法，是计算机编程技术发展到一定阶段后产生的一种软件开发方法，具有抽象、封装、继承、多态等特征，还形成设计原则和设计模式的智慧结晶。我们可以使用一张图来更为形象地展现面向对象所涉及内容之间的关系，如图3.21所示。

图3.21

面向对象的特征

面向对象的特征如下。

(1)封装：指将相关属性和方法重组成一个新的对象，并提供对外访问的接口，对数据的访问或修改只能通过该接口进行。电商商品有拍下和支付等行为特征，但其实现细节对用户来说是不可见的，所以在进行商品购买的过程中，用户并不清楚交易是如何进行的，以及订单的状态是如何发生改变的，这就体现了对象的封装性。

(2)继承：指某类对象可以继承其他类对象的属性和方法，是一种类之间的层次关系表达。继承有单继承与多继承两种方式：单继承指子类只有一个父类；多继承指子类有一个以上的父类。继承是代码重用的具体表现之一，也破坏了对象的封装性，父类的公共属性和方法对子类开放，如果修改父类的公共属性和方法，就会导致所有子类的改变，这在一定程度上其实破坏了系统的可扩展性。

(3)多态：指不同的类对象对同一消息做出响应，但同一消息可以根据发送的不同对象进行不同的处理，最终得到不同的执行结果。

接口的不同实现方式也被称为多态。

(4)抽象：指为了达到某种目的，对涉及的信息和现象进行过滤，将共性元素进行合并，这些元素同时具有独立性和特殊性。抽象也是面向对象分析与设计的基础。

面向对象设计的原则

为了设计出一个好的软件系统，就必须遵照一定的规则，而衡量软件设计质量的首要标准就是该设计能否满足软件的功能需求。除了功能需求，还有很多衡量软件设计质量的标准，主要包括高内聚、低耦合、可扩展和可复用。

(1)高内聚：系统中的模块具有高度相关的职责，如果除了这些职责内的任务，没有过多的其他任务，该模块就具有高内聚性，反之具有低内聚性。并且系统中的模块与模块之间有较高的协作性，也就是常说的单一责任原则。

(2)低耦合：耦合指元素与元素之间连接、感知和依赖的程度。这里所说的元素，可以指功能、对象(类)，也可以指系统、子系统、模块。耦合度越低，系统越独立，可扩展性就会越好，所以在设计系统时首先要考虑对元素的划分。

(3)可扩展：用于应对更大规模的业务及软件的成长，通常采用动态加载的插件、回调函数、抽象接口及认真设计的代码结构和类层次结构，使系统在面对不断变化的需求时，其代码不被大量重构开发，比如添加新功能或修改完善现有功能。

(4)可复用：又叫作重用，即重复使用，可以利用已有的代码或者相关模块去实现新的功能需求，实现高效、低成本和高质量。

面向对象是一种解决现实问题的思想，让我们把重点放在现实的客体上。我们可以通过 UML弄清楚这些客体之间的关系，最后把客体与客体之间的关系用面向对象的语言表达出来。客体与客体之间的关系如图3.22所示。

图3.22

回顾前面介绍的将大象放入冰箱的例子，我们如何使用面向对象思想实现这个例子呢？首先，找出现实世界中的动作和实体：①打开冰箱；②将大象放入冰箱；③关闭冰箱。然后，抽象出概念：①冰箱、可以打开门、可以存储、可以关门；②大象、体重、体积。最后，用计算机中的类来实现该逻辑关系，这样就有了elephant和fridge两个类。

面向对象的代码实现如下：

虽然面向对象起初专指在程序设计中采用封装、继承、多态、抽象等设计方法，然而现在它已经渗透到软件开发的各个方面，比如面向对象的分析(OOA)、面向对象的设计(OOD)和面向对象的编程(OOP)等环节，其在各环节的职责如下。

(1)在需求分析阶段采用面向对象的分析方法，这个阶段不需要思考怎么用程序实现它，只需要思考和分析需求中稳定不变的客体是什么，这些客体之间的关系又是什么，以及完成概要建模。

(2)在设计阶段采用面向对象的设计方法，把在需求分析阶段分析出来的需求进一步扩充为模型，变成可实现的、符合成本的、模块化的、低耦合高内聚的模型。

(3)在编程开发阶段采用面向对象的编程语言来具体实现在前一个阶段得到的业务模型。

面向服务分析与设计

面向服务(SOA)是一种架构思想，可以是跨语言的，也可以是跨平台的，其宗旨就是根据项目的服务完成架构搭建，以服务为基准点完成系统的组件化和模块化。比如，在电商系统中提供商品搜索服务、商品查询服务、用户信息服务、订单查询服务，等等，这些都是由电商系统提供的服务，这些服务由一个个的业务点组成，一个服务就是一条业务线，整个项目的服务体系可以说是由各种各样的业务点组成的，并由业务线串联而成，而服务的实现过程就是面向服务分析与设计。

Web Service模式

在Web Service模式下，服务提供者创建服务，并决定将其公开并发布。发布是通过将服务信息发布到服务目录上来完成的。另外，服务消费者将在服务目录中搜索满足必要条件的服务，在找到服务后，通过服务目录中的可用服务信息，就能够以正确的方式直接调用服务提供者，从而满足业务的需求。其过程如图3.23所示。

图3.23

对Web Service中的一些术语解释说明如下。

◎ 服务提供者：指服用的被调用方，即为其他服务提供服务的服务。

◎ 服务消费者：指服务的调用方，即依赖其他服务的服务。

◎ 服务目录：用于向消费者提供可以用的服务目录。

◎ SOAP(Simple Object Access Protocol，简单对象访问协议)：是交换数据的一种协议规范，是一种轻量的、简单的、基于XML 的协议，它被设计成在 Web 上交换结构化的和固定化的信息。

◎ WSDL(Web Service Description Language，Web服务描述语言)：用来描述Web服务发布的XML格式。

◎ UDDI ( Universal Description Discovery andIntegration)：指通用的描述、发现、集成服务，用来存储服务信息的目录及描述服务界面的目录。我们可以通过 UDDI根据自己的需要动态查找并使用We b服务，也可以将自己的We b服务动态发布到UDDI注册中心，供其他用户使用。

ESB模式

ESB(Enterprise Service Bus，企业服务总线)提供服务对接、协议转换、消息传输、数据转换、内容路由等功能，隐藏了服务提供者的物理位置、协议和数据格式，由中间件产品技术实现，通过事件驱动和XML消息引擎为更复杂的面向服务的架构提供服务。ESB通常在企业的消息系统上提供一个抽象层，可以帮助设计者利用消息(不用编码)就能完成集成工作，其架构如图3.24所示。

图3.24

微服务架构

微服务架构是SOA架构的延续，是一种比较现代化的细粒度的SOA实现方式，强调业务需要彻底组件化和服务化，也就是说，系统需要按照业务边界做细粒度的拆分和部署。这样，原有的单个业务系统会被拆分为多个可以独立开发、设计和运行的微服务系统，这些微服务之间通过REST(Representational State Transfer)完成交互和集成。

那么，微服务架构又具有什么样的特点呢？可简单归纳为如下三点。

(1)独立部署、灵活扩展。传统的单体架构是以整个系统为单位进行部署的，而微服务架构是以每一个独立组件为单位进行部署的，可以根据每个服务的高并发要求的不同进行不同的部署。比如，服务A需要部署10台机器，服务B需要部署20台机器，而服务C只需要部署3台机器，像这种灵活的部署方案只有微服务架构才能实现，近几年流行的容器化更为微服务架构提供了高效、灵活的部署方案。

(2)资源的有效隔离。微服务设计的原则之一，就是每一个微服务都拥有独立的数据源，假如微服务 A想要读写微服务 B的数据库，则只能调用微服务 B对外暴露的接口来完成，这样就有效避免了服务之间争用数据库和缓存资源所带来的问题。另外，由于每一个微服务实例都运行在不同的容器中，所以更好地实现了服务器资源(比如内存、CPU等)的隔离，如图3.25所示。

图3.25

(3)敏捷的组织结构。微服务设计的思想也改变了原有的企业研发团队的组织架构，从以往水平的职能型团队变成了垂直的业务型团队。职能型团队和业务型团队的架构如图 3.26和图3.27所示。

图3.26

图3.27

当然，微服务架构也带来了各种各样的问题，如下所述。

◎ 微服务架构把原有的项目拆成多个独立的工程，增加了开发、测试和运维的复杂度。◎ 微服务架构需要保证不同服务之间的数据一致性，引入了分布式事物和最终一致性机制，为设计和开发带来了挑战。

◎ 很多微服务的拆分粒度过大，导致服务的调用链过长，性能降低，维护成本增加。

领域驱动设计可以弥补微服务架构中的很多不足，为微服务架构提供指导思想，比如服务拆分的粒度和事务合理设计等，下面重点介绍领域驱动设计的详细方法。

本文给大家讲解的内容是程序员技术精进： 面向对象与服务的分析与设计

1. 下篇文章给大家讲解的是程序员技术精进： 领域驱动设计， 领域模型实践；
2. 觉得文章不错的朋友可以转发此文关注小编；
3. 感谢大家的支持！