什么是面向对象？ 面向对象的概念是什么？(2)

什么是面向对象

抽象有两种方式：

• 自顶向下：自顶向下的方法适用于让人们从头开始认识一个事物。先宏观后微观
• 自底向上：自底向上的方法适用于在实践中改进和提高认识。先微观后宏观

映射到我们的软件开发过程中，我们往往会采用自顶向下的方式，先搭建一个框架，用少量粗粒度的概念来覆盖系统的需求，再逐步细化，降低抽象的层次。

同时在细化的过程中，我们也能够通过细节间的相同之处，来改进较高层次的抽象范围。

因此这两种方式应当是相辅相成，而不是两者择一的关系。

根据抽象而成的对象理应具备以下特征：

• 对象都具有原子性无论在什么时候，在同一抽象层次上，在分析过程中都应当将对象视为一个不可分割的原子，哪怕这个对象的规模很大。
• 对象都是可抽象的对象所具有的方面，或者说对象所参与的场景越多，对象越有抽象价值，反之则越没有抽象价值
• 对象都有层次性对象是有着抽象层次的。层次越高，其描述越粗略但适应能力越广；层次越低则描述越精确但适应能力越下降

参与者

参与者的角色在建模过程中是处于核心地位的。

他们是处于系统范围之外，居于业务范围之内与系统进行交互的。

参与者和系统之间有一个明确的边界，参与者只可能存在于边界之外，边界之内（系统之内）的所有人或事都不是参与者。

如果参与者涉及到了系统边界之内，那么此时参与者的角色就是可疑的，需要重新定义。

因此在业务设计阶段，一定要坚守好这道边界，参与者过早侵入系统就可能会对系统造成损害。

什么是参与者？简单定义如下：

• 谁将使用此功能
• 谁对某个特定功能感兴趣
• 谁负责支持和维护系统参与者一定是直接并且主动地向系统发出动作并获得反馈的，否则就不是参与者

在实际业务分析阶段，我们需要区分业务范围和系统范围

• 业务范围：是指项目所涉及的全部客户业务领域，不论是否涉及开发系统的参与，这些业务都是客观存在的
• 系统范围：是指软件系统将要实现的那一部分功能，这些功能是从业务范围中提取，是业务范围的一个子集

如果在业务分析阶段就预设了计算机系统的存在，那么将会混淆现有业务和将来实际开发的业务，将用户代入到计算机系统中，可能会造成现有业务属性的削弱，而忽略了实际业务背后的含义。

当然，这也是开发人员对接业务需求的一大误区之一。喜欢从计算机系统的角度来思考问题，在向客户收集需求的时候总是在第一时间想到计算机将如何实现它，常常津津乐道于跟客户讨论背后的系统将如何实现客户的需求，并且指望客户能够用这种方式来确认需求。带来的危害：

• 客户不能理解将来的落地实现是什么样子的，但是出于信任开发人员，就会将信将疑地做出肯定
• 开发人员在一开始就加入了自己的主观判断，假设了业务在计算机系统里的实现方式，而没有真正地去理解客户的实际业务

用例

用例是一种描述系统如何与外部用户或其他系统进行交互的技术工具。它描述了系统的功能和行为，并以用户的角度来描述系统的需求和使用场景。简言之：用例是用来捕捉功能性需求

在软件开发阶段，我们会以用例作为最小指导单元进行设计，标准的用例应当具备以下特征：

• 用例是相对独立的
• 用例的执行结果对参与者来说是可观测的和有意义的用例的粒度大小不是从用例包含的步骤的多少来判断的，而是每一个用例能尽量能够说明一件完整的事情

用例的获取并非来源于开发人员，换言之，开发人员是用例的翻译者。用例的定义是参与者驱动的，这也对应了用例的特征之一：用例的执行结果对参与者来说是可观测的和有意义的。因此用例的来源就是参与者对系统的期望。所以发现用例的前提条件就是发现参与者，确定参与者的同时就确定了系统边界。

Code without understanding the business is like playing the rogue结合业务，与参与者聊需求的时候经常感觉需求飘渺不定，每个点都感觉是需求的核心部分。那么是否有认真想过：参与者想做和要做的事情不一定是他真实的目标，也许只是他做事情的一个步骤

• 一个明确有效的目标才是一个用例的来源
• 一个真实的目标应当完备地表达参与者的期望
• 一个有效的目标应当在系统边界内，由参与者发动，并具有明确的后果

在软件开发需要耗时最久是哪个阶段？应该是需求分析和设计阶段。为了缩短开发周期，很容易想到便是缩减需求分析和设计阶段的时间，当你真的这么做了，你可能就会离真正的用例愈偏愈远！要平衡时间和质量，就需要充分理解用户需求，当访谈不顺利的时候应当重新调整策略，调整系统边界的规模或者更换访谈的参与者都是不错的选择。

用例不是功能点在大多数开发者看来用例是一个功能点。然而实际情况并非如此。功能的生命周期：输入->计算->输出，功能是脱离使用者的愿望而存在的，本身是孤立的。

类似一个判断用户是否有操作权限的方法，这个方法本身是脱离业务的，它的用例场景可能是用户在提交某个模块下的变更记录，才需要校验权限，而校验权限只是其中的一个功能。

在实际情况下，更应当从使用者的观点去描述，一个用例是一个参与者如何使用系统，获得什么结果的一个集合，那么此时用例可以解释为一系列完成一个特定目标的功能的组合，针对不同的应用场景，这些功能可以以不同的组合方式构建出新的用例。

步骤不是目标一个用例是参与者对目标的一个期望。在完成这个目标之前需要经由很多步骤，但每个步骤并不能完整地反映出参与者的目标，因此作为一个用例是有所缺陷的。错误地使用步骤作为用例，将无法准确地描述参与者如何使用系统，整体系统的操作流程以及交互细节会发生偏差，脱离预期。

目标和步骤很容易造成混淆，在弄清楚目标与步骤之前，我们就需要设置一些实际场景来解释，通过场景中涉及到的问题来测试出什么才是参与者真正的目的。

可能在此之前参与者也不清楚自己想要的到底是什么！

至此，回想《领域驱动设计-软件核心复杂性应对之道》自问世以来，带来了一个全新的思想：领域驱动设计。重点传述的也是通过领域设计来分离业务复杂度和技术复杂度。复杂度也许永远不能消除，但我们可以分析复杂度，进而管理复杂度。书中有提到：

每个软件程序是为了执行用户的某项活动，或是满足用户的某种需求。这些用户应用软件的问题区域就是软件的领域。

回过头来看上述所讲到的面向对象，不乏有相同之处。某种程度上，把“领域驱动设计”改为“模型驱动设计”也相当贴切。

回收开头的问题，我认为：需求复杂度 != 技术复杂度，建模理应成为我们管理复杂度的工具！