面向对象你是怎么理解的

    对象模型 　　对象模型表示了静态的、结构化的系统数据性质，描述了系统的静态结构，它是从客观世界实体的对象关系角度来描述，表现了对象的相互关系。该模型主要关心系统中对象的结构、属性和操作，它是分析阶段三个模型的核心，是其他两个模型的框架。
   　　⒈对象和类 　　⑴ 对象。   　　对象建模的目的就是描述对象。 　　⑵ 类。 　　通过将对象抽象成类，我们可以使问题抽象化，抽象增强了模型的归纳能力。 　　⑶ 属性。
   　　属性指的是类中对象所具有的性质（数据值）。 　　⑷ 操作和方法。 　　操作是类中对象所使用的一种功能或变换。  类中的各对象可以共享操作，每个操作都有一个目标对象作为其隐含参数。
   　　方法是类的操作的实现步骤。 　　⒉关联和链 　　关联是建立类之间关系的一种手段，而链则是建立对象之间关系的一种手段。 　　⑴ 关联和链的含义。 　　链表示对象间的物理与概念联结，关联表示类之间的一种关系，链是关联的实例，关联是链的抽象。
     　　⑵ 角色。 　　角色说明类在关联中的作用，它位于关联的端点。 　　⑶ 受限关联。 　　受限关联由两个类及一个限定词组成，限定词是一种特定的属性，用来有效的减少关联的重数，限定词在关联的终端对象集中说明。
   　　限定提高了语义的精确性，增强了查询能力，在现实世界中，常常出现限定词。   　　⑷ 关联的多重性。 　　关联的多重性是指类中有多少个对象与关联的类的一个对象相关。
  重数常描述为“一”或“多”。 　　⒊类的层次结构 　　⑴ 聚集关系。 　　聚集是一种“整体－部分”关系。在这种关系中，有整体类和部分类之分。聚集最重要的性质是传递性，也具有逆对称性。   　　聚集可以有不同层次，可以把不同分类聚集起来得到一颗简单的聚集树，聚集树是一种简单表示，比画很多线来将部分类联系起来简单得多，对象模型应该容易地反映各级层次。
   　　⑵一般化关系。 　　一般化关系是在保留对象差异的同时共享对象相似性的一种高度抽象方式。它是“一般---具体”的关系。  一般化类称为你类，具体类又能称为子类，各子类继承了父类的性质，而各子类的一些共同性质和操作又归纳到你类中。
  因此，一般化关系和继承是同时存在的。一般化关系的符号表示是在类关联的连线上加一个小三角形。 　　⒋对象模型 　　⑴模板。模板是类、关联、一般化结构的逻辑组成。   　　⑵对象模型。
   　　对象模型是由一个或若干个模板组成。模板将模型分为若干个便于管理的子块，在整个对象模型和类及关联的构造块之间，模板提供了一种集成的中间单元，模板中的类名及关联名是唯一的。 动态模型 　　动态模型是与时间和变化有关的系统性质。
  该模型描述了系统的控制结构，它表示了瞬间的、行为化的系统控制 　　性质，它关心的是系统的控制，操作的执行顺序，它表示从对象的事件和状态的角度出发，表现了对象的相互行为。   　　该模型描述的系统属性是触发事件、事件序列、状态、事件与状态的组织。
  使用状态图作为描述工具。它涉及到事件、状态、操作等重要概念。 　　⒈事件 　　事件是指定时刻发生的某件事。 　　⒉状态 　　状态是对象属性值的抽象。对象的属性值按照影响对象显著行为的性质将其归并到一个状态中去。
    状态指明了对象对输入事件的响应。 　　⒊状态图 　　状态图是一个标准的计算机概念，他是有限自动机的图形表示，这里把状态图作为建立动态模型的图形工具。 　　状态图反映了状态与事件的关系。
  当接收一事件时，下一状态就取决于当前状态和所接收的该事件，由该事件引起的状态变化称为转换。   　　状态图是一种图，用结点表示状态，结点用圆圈表示；圆圈内有状态名，用箭头连线表示状态的转换，上面标记事件名，箭头方向表示转换的方向。
   功能模型 　　功能模型描述了系统的所有计算。功能模型指出发生了什么，动态模型确定什么时候发生，而对象模型确定发生的客体。  功能模型表明一个计算如何从输入值得到输出值，它不考虑计算的次序。
  功能模型由多张数据流图组成。数据流图用来表示从源对象到目标对象的数据值的流向，它不包含控制信息，控制信息在动态模型中表示，同时数据流图也不表示对象中值的组织，值的组织在对象模型中表示。图10-15给出了一个窗口系统的图标显示的数据流图。
     　　数据流图中包含有处理、数据流、动作对象和数据存储对象。 　　⒈处理 　　数据流图中的处理用来改变数据值。最低层处理是纯粹的函数，一张完整的数据流图是一个高层处理。
   　　⒉数据流 　　数据流图中的数据流将对象的输出与处理、处理与对象的输入、处理与处理联系起来。  在一个计算机中，用数据流来表示一中间数据值，数据流不能改变数据值。 　　⒊动作对象 　　动作对象是一种主动对象，它通过生成或者使用数据值来驱动数据流图。
   　　⒋数据存储对象 　　数据流图中的数据存储是被动对象，它用来存储数据。它与动作对象不一样，数据存储本身不产生任何操作，它只响应存储和访问的要求。   　　对象的引入和应用 　　对象支持继承（inheritance）的概念，即一个派生类（derived class）继承基类（base class）的字段和方法。
  继承也允许把一个派生类的对象作为一个基类对象对待。例如，有这样一个设计：一个Dog类型的对象派生自Animal类，这是模拟“是一个（is-a）”关系（例图，Dog是一个Animal）。  这样，可以隐式地把一个Dog类型的引用转换成Animal类型。
  这里的隐式是指这个转换以一个简单的赋值表达式形式进行。反之，如果某个Animal类型的对象引用指向的是一个Dog类创建的对象，可以通过转换操作符显式地把一个Animal类型引用转换成Dog类型。
  这个概念称为多态（polymorphism），即可以操作相关类型的对象，好像它们是同一种公共类型一样。   编辑本段 分析 　　面向对象分析的目的是对客观世界的系统进行建模。
  本节以上面介绍的模型概念为基础，结合“银行网络系统”的具体实例来构造客观世界问题的准确、严密的分析模型。 　　分析模型有三种用途：用来明确问题需求；为用户和开发人员提供明确需求；为用户和开发人员提供一个协商的基础，作为后继的设计和实现的框架。
     　　（一） 面向对象的分析 　　系统分析的第一步是：陈述需求。分析者必须同用户一块工作来提炼需求，因为这样才表示了用户的真实意图，其中涉及对需求的分析及查找丢失的信息。
  下面以“银行网络系统”为例，用面向对象方法进行开发。 　　银行网络系统问题陈述：设计支持银行网络的软件，银行网络包括人工出纳站和分行共享的自动出纳机。  每个分理处用分理处计算机来保存各自的帐户，处理各自的事务；各自分理处的出纳站与分理处计算机通信，出纳站录入帐户和事务数据；自动出纳机与分行计算机通信，分行计算机与拨款分理处结帐，自动出纳机与用户接口接受现金卡，与分行计算机通信完成事务，发放现金，打印收据；系统需要记录保管和安全措施；系统必须正确处理同一帐户的并发访问；每个分处理为自己的计算机准备软件，银行网络费用根据顾客和现金卡的数目分摊给各分理处。
     　　图10－18给出银行网络系统的示意图。 　　（二）建立对象模型 　　首先标识和关联，因为它们影响了整体结构和解决问题的方法，其次是增加属性，进一步描述类和关联的基本网络，使用继承合并和组织类，最后操作增加到类中去作为构造动态模型和功能模型的副产品。
   　　⒈确定类 　　构造对象模型的第一步是标出来自问题域的相关的对象类，对象包括物理实体和概念。  所有类在应用中都必须有意义，在问题陈述中，并非所有类都是明显给出的。
  有些是隐含在问题域或一般知识中的。 　　按图10-19所示的过程确定类 　　查找问题陈述中的所有名词，产生如下的暂定类。 　　软件 银行网络 出纳员 自动出纳机 分行 　　分处理 分处理计算机 帐户 事务 出纳站 　　事务数据 分行计算机 现金卡 用户 现金 　　收据 系统 顾客 费用 帐户数据 　　访问 安全措施 记录保管 　　根据下列标准，去掉不必要的类和不正确的类。
     　　⑴ 冗余类：若两个类表述了同一个信息 ，保留最富有描述能力的类。如"用户"和"顾客"就是重复的描述，因为"顾客"最富有描述性，因此保留它。 　　⑵ 不相干的类：除掉与问题没有关系或根本无关的类。
  例如，摊派费用超出了银行网络的范围。 　　⑶ 模糊类：类必须是确定的，有些暂定类边界定义模糊或范围太广，如"记录保管"就模糊类，它是"事务"中的一部分。   　　⑷ 属性：某些名词描述的是其他对象的属性，则从暂定类中删除。
  如果某一性质的独立性很重要，就应该把他归属到类，而不把它作为属性。 　　⑸ 操作：如果问题陈述中的名词有动作含义，则描述的操作就不是类。但是具有自身性质而且需要独立存在的操作应该描述成类。如我们只构造电话模型，"拨号"就是动态模型的一部分而不是类，但在电话拨号系统中，"拨号"是一个重要的类，它日期、时间、受话地点等属性。
     　　在银行网络系统中，模糊类是"系统"、"安全措施"、"记录保管"、"银行网络"等。属于属性的有："帐户数据"、"收据"、"现金"、"事务数据"。属于实现的如："访问"、"软件"等。
  这些均应除去。 　　⒉准备数据字典 　　为所有建模实体准备一个数据字典。  准确描述各个类的精确含义，描述当前问题中的类的范围，包括对类的成员、用法方面的假设或限制。 　　⒊确定关联 　　两个或多个类之间的相互依赖就是关联。
  一种依赖表示一种关联，可用各种方式来实现关联，但在分析模型中应删除实现的考虑，以便设计时更为灵活。关联常用描述性动词或动词词组来表示，其中有物理位置的表示、传导的动作、通信、所有者关系、条件的满足等。
    从问题陈述中抽取所有可能的关联表述，把它们记下来，但不要过早去细化这些表述。 　　下面是银行网络系统中所有可能的关联，大多数是直接抽取问题中的动词词组而得到的。在陈述中，有些动词词组表述的关联是不明显的。
  最后，还有一些关联与客观世界或人的假设有关，必须同用户一起核实这种关联，因为这种关联在问题陈述中找不到。   　　银行网络问题陈述中的关联： 　　·银行网络包括出纳站和自动出纳机； 　　·分行共享自动出纳机； 　　·分理处提供分理处计算机； 　　·分理处计算机保存帐户； 　　·分理处计算机处理帐户支付事务； 　　·分理处拥有出纳站； 　　·出纳站与分理处计算机通信； 　　·出纳员为帐户录入事务； 　　·自动出纳机接受现金卡； 　　·自动出纳机与用户接口； 　　·自动出纳机发放现金； 　　·自动出纳机打印收据； 　　·系统处理并发访问； 　　·分理处提供软件； 　　·费用分摊给分理处。
     　　隐含的动词词组： 　　·分行由分理处组成； 　　·分理处拥有帐户； 　　·分行拥有分行计算机； 　　·系统提供记录保管； 　　·系统提供安全； 　　·顾客有现金卡。
   　　基于问题域知识的关联： 　　·分理处雇佣出纳员； 　　·现金卡访问帐户。   　　使用下列标准去掉不必要和不正确的关联： 　　⑴ 若某个类已被删除，那么与它有关的关联也必须删除或者用其它类来重新表述。
  在例中，我们删除了"银行网络"，相关的关联也要删除。 　　⑵ 不相干的关联或实现阶段的关联：删除所有问题域之外的关联或涉及实现结构中的关联。  如"系统处理并发访问"就是一种实现的概念。
   　　⑶ 动作：关联应该描述应用域的结构性质而不是瞬时事件，因此应删除"自动出纳机接受现金卡"，"自动出纳机与用户接口"等。 　　⑷ 派生关联：省略那些可以用其他关联来定义的关联。因为这种关联是冗余的。
  银行网络系统的初步对象图如图10-20所示。  其中含有关联。 　　⒋确定属性 　　属性是个体对象的性质，属性通常用修饰性的名词词组来表示。形容词常常表示具体的可枚举的属性值，属性不可能在问题陈述中完全表述出来，必须借助于应用域的知识及对客观世界的知识才可以找到它们。
  只考虑与具体应用直接相关的属性，不要考虑那些超出问题范围的属性。  首先找出重要属性，避免那些只用于实现的属性，要为各个属性取有意义的名字。按下列标准删除不必要的和不正确的属性： 　　⑴ 对象：若实体的独立存在比它的值重要，那么这个实体不是属性而是对象。
  如在邮政目录中，"城市"是一个属性，然而在人口普查中，"城市"则被看作是对象。  在具体应用中，具有自身性质的实体一定是对象。 　　⑵ 定词：若属性值取决于某种具体上下文，则可考虑把该属性重新表述为一个限定词。
   　　⑶ 名称：名称常常作为限定词而不是对象的属性，当名称不依赖于上下文关系时，名称即为一个对象属性，尤其是它不惟一时。 　　⑷ 标识符：在考虑对象模糊性时，引入对象标识符表示，在对象模型中不列出这些对象标识符，它是隐含在对象模型中，只列出存在于应用域的属性。
     　　⑸ 内部值：若属性描述了对外不透明的对象的内部状态，则应从对象模型中删除该属性。 　　⑹ 细化：忽略那些不可能对大多数操作有影响的属性。 　　⒌使用继承来细化类 　　使用继承来共享公共机构，以次来组织类，可以用两种方式来进行。
   　　⑴ 自底向上通过把现有类的共同性质一般化为父类，寻找具有相似的属性，关系或操作的类来发现继承。  例如"远程事务"和"出纳事务"是类似的，可以一般化为"事务"。有些一般化结构常常是基于客观世界边界的现有分类，只要可能，尽量使用现有概念。
  对称性常有助于发现某些丢失的类。 　　⑵ 自顶向下将现有的类细化为更具体的子类。具体化常常可以从应用域中明显看出来。应用域中各枚举字情况是最常见的具体化的来源。  例如：菜单，可以有固定菜单，顶部菜单，弹出菜单，下拉菜单等，这就可以把菜单类具体细化为各种具体菜单的子类。
  当同一关联名出现多次且意义也相同时，应尽量具体化为相关联的类，例如"事务"从"出纳站"和"自动出纳机"进入，则"录入站"就是"出纳站"和"自动出纳站"的一般化。  在类层次中，可以为具体的类分配属性和关联。
  各属性和都应分配给最一般的适合的类，有时也加上一些修正。 　　应用域中各枚举情况是最常见的具体化的来源。 　　⒍完善对象模型 　　对象建模不可能一次就能保证模型是完全正确的，软件开发的整个过程就是一个不断完善的过程。
    模型的不同组成部分多半是在不同的阶段完成的，如果发现模型的缺陷，就必须返回到前期阶段去修改，有些细化工作是在动态模型和功能模型完成之后才开始进行的。 　　⑴ 几种可能丢失对象的情况及解决办法： 　　·同一类中存在毫无关系的属性和操作，则分解这个类，使各部分相互关联； 　　·一般化体系不清楚，则可能分离扮演两种角色的类 　　·存在无目标类的操作，则找出并加上失去目标的类； 　　·存在名称及目的相同的冗余关联，则通过一般化创建丢失的父类，把关联组织在一起。
     　　⑵ 查找多余的类。 　　类中缺少属性，操作和关联，则可删除这个类。 　　⑶查找丢失的关联。 　　丢失了操作的访问路径，则加入新的关联以回答查询。 　　⑷ 网络系统的具体情况作如下的修改： 　　①现金卡有多个独立的特性。
  把它分解为两个对象：卡片权限和现金卡。   　　a。卡片权限：它是银行用来鉴别用户访问权限的卡片，表示一个或多个用户帐户的访问权限；各个卡片权限对象中可能具有好几个现金卡，每张都带有安全码，卡片码，它们附在现金卡上，表现银行的卡片权限。
   　　b。现金卡：它是自动出纳机得到表示码的数据卡片，它也是银行代码和现金卡代码的数据载体。   　　②"事务"不能体现对帐户之间的传输描述的一般性，因它只涉及一个帐户，一般来说，在每个帐户中，一个"事务"包括一个或多个"更新"，一个"更新"是对帐户的一个动作，它们是取款，存款，查询之一。
  一个"更新"中所有"更新"应该是一个原子操作。 　　③"分理处"和"分离处理机"之间，"分行"和"分行处理机"之间的区别似乎并不影响分析，计算机的通信处理实际上是实现的概念，将"分理处计算机"并入到"分理处"，将"分行计算机"并入到"分行"。
     　　（三）建立动态模型 　　⒈准备脚本 　　动态分析从寻找事件开始，然后确定各对象的可能事件顺序。在分析阶段不考虑算法的执行，算法是实现模型的一部分。 　　⒉确定事件 　　确定所有外部事件。
  事件包括所有来自或发往用户的信息、外部设备的信号、输入、转换和动作，可以发现正常事件，但不能遗漏条件和异常事件。   　　⒊准备事件跟踪表 　　把脚本表示成一个事件跟踪表，即不同对象之间的事件排序表，对象为表中的列，给每个对象分配一个独立的列。
   　　⒋构造状态图 　　对各对象类建立状态图，反映对象接收和发送的事件，每个事件跟踪都对应于状态图中一条路径。 　　（四）建立功能建模 　　功能模型用来说明值是如何计算的，表明值之间的依赖关系及相关的功能，数据流图有助于表示功能依赖关系，其中的处理应于状态图的活动和动作，其中的数据流对应于对象图中的对象或属性。
     　　⒈确定输入值、输出值 　　先列出输入、输出值，输入、输出值是系统与外界之间的事件的参数。 　　⒉建立数据流图 　　数据流图说明输出值是怎样从输入值得来的，数据流图通常按层次组织。
   　　（五）确定操作 　　在建立对象模型时，确定了类、关联、结构和属性，还没有确定操作。  只有建立了动态模型和功能模型之后，才可能最后确定类的操作。 编辑本段 设计 　　面向对象设计是把分析阶段得到的需求转变成符合成本和质量要求的、抽象的系统实现方案的过程。
  从面向对象分析到面向对象设计，是一个逐渐扩充模型的过程。 　　瀑布模型把设计进一步划分成概要设计和详细设计两个阶段，类似地，也可以把面向对象设计再细分为系统设计和对象设计。  系统设计确定实现系统的策略和目标系统的高层结构。
  对象设计确定解空间中的类、关联、接口形式及实现操作的算法。 　　（一）面向对象设计的准则 　　⒈模块化 　　面向对象开发方法很自然地支持了把系统分解成模块的设计原则：对象就是模块。它是把数据结构和操作这些数据的方法紧密地结合在一起所构成的模块。
    分解系统为一组具有高内聚和松耦合的模块是模块化的属性。 　　⒉抽象 　　面向对象方法不仅支持过程抽象，而且支持数据抽象。 　　⒊信息隐藏 　　在面向对象方法中，信息隐藏通过对象的封装性来实现。
   　　⒋低耦合 　　在面向对象方法中，对象是最基本的模块，因此，耦合主要指不同对象之间相互关联的紧密程度。  低耦合是设计的一个重要标准，因为这有助于使得系统中某一部分的变化对其它部分的影响降到最低程度。
   　　⒌高内聚 　　⑴操作内聚。 　　⑵类内聚。 　　⑶一般——具体内聚。 　　（二）面向对象设计的启发规则 　　⒈设计结果应该清晰易懂 　　使设计结果清晰、易懂、易读是提高软件可维护性和可重用性的重要措施。
    显然，人们不会重用那些他们不理解的设计。 　　要做到： 　　⑴用词一致。 　　⑵使用已有的协议。 　　⑶减少消息模式的数量。 　　⑷避免模糊的定义。 　　⒉一般——具体结构的深度应适当 　　⒊设计简单类 　　应该尽量设计小而简单的类，这样便以开发和管理。
    为了保持简单，应注意以下几点： 　　⑴避免包含过多的属性。 　　⑵有明确的定义。 　　⑶尽量简化对象之间的合作关系。 　　⑷不要提供太多的操作。 　　⒋使用简单的协议 　　一般来说，消息中参数不要超过3个。
   　　⒌使用简单的操作 　　面向对象设计出来的类中的操作通常都很小，一般只有3至5行源程序语句，可以用仅含一个动词和一个宾语的简单句子描述它的功能 　　⒍把设计变动减至最小 　　通常，设计的质量越高，设计结果保持不变的时间也越长。
    即使出现必须修改设计的情况，也应该使修改的范围尽可能小。 　　（三）系统设计 　　系统设计是问题求解及建立解答的高级策略。必须制定解决问题的基该方法，系统的高层结构形式包括子系统的分解、它的固有并发性、子系统分配给硬软件、数据存储管理、资源协调、软件控制实现、人机交互接口。
     　　⒈系统设计概述 　　设计阶段先从高层入手，然后细化。系统设计要决定整个结构及风格，这种结构为后面设计阶段的更详细策略的设计提供了基础。 　　⑴系统分解。 　　系统中主要的组成部分称为子系统，子系统既不是一个对象也不是一个功能，而是类、关联、操作、事件和约束的集合。
     　　⑵确定并发性。 　　分析模型、现实世界及硬件中不少对象均是并发的。 　　⑶处理器及任务分配。 　　各并发子系统必须分配给单个硬件单元，要么是一个一般的处理器，要么是一个具体的功能单元。
   　　⑷数据存储管理。 　　系统中的内部数据和外部数据的存储管理是一项重要的任务。  通常各数据存储可以将数据结构、文件、数据库组合在一起，不同数据存储要在费用、访问时间、容量及可靠性之间做出折衷考虑。
   　　⑸全局资源的处理。 　　必须确定全局资源，并且制定访问全局资源的策略。 　　⑹选择软件控制机制。 　　分析模型中所有交互行为都表示为对象之间的事件。  系统设计必须从多种方法中选择某种方法来实现软件的控制。
   　　⑺人机交互接口设计。 　　设计中的大部分工作都与稳定的状态行为有关，但必须考虑用户使用系统的交互接口。 　　⒉系统结构的一般框架 　　⒊系统分解——建立系统的体系结构 　　可用的软件库以及程序员的编程经验。
     　　通过面向对象分析得到的问题域精确模型，为设计体系结构奠定了良好的基础，建立了完整的框架。 　　⒋选择软件控制机制 　　软件系统中存在两种控制流，外部控制流和内部控制流。
   　　⒌数据存储管理 　　数据存储管理是系统存储或检索对象的基本设施，它建立在某种数据存储管理系统之上，并且隔离了数据存储管理模式的影响。   　　⒍设计人机交互接口 　　在面向对象分析过程中，已经对用户界面需求作了初步分析，在面向对象设计过程中，则应该对系统的人机交互接口进行详细设计，以确定人机交互的细节，其中包括指定窗口和报表的形式、设计命令层次等项内容。
   　　（四）对象设计 　　⒈对象设计概述 　　⒉三种模型的结合 　　⑴获得操作。   　　⑵确定操作的目标对象。 　　⒊算法设计 　　⒋优化设计 　　⒌控制的实现 　　⒍调整继承 　　⒎关联的设计。