UML4理解面向对象(类图).ppt

UML建模技术 理解面向对象 如何理解面向对象思维方式 ,介绍grasp模式 一些面向对象的概念 对象如何与其他对象关联 如何理解面向对象思维方式? 举例 以洗衣机类为例，它具有商标铭牌﹑型号﹑条形码和容量等属性，还有”放入衣物” ﹑”放入洗衣粉” ﹑”开机” 和”关机” 等操作，就有了制造WashingMachine类新实例的机制。也就是说，可以基于洗衣机这个类创建新的对象。 洗衣机类图 对象是一个类实例，是量化的，具体的事物，是动态的概念。 类是对象的泛化和共性，是静态的概念。 类/对象具有属性和操作，属性和操作称为特征。前者是类/对象的静态特征，后者是类/对象的动态特征。 特征的可见性 公有(Public)：类的对象任意访问该特征 保护(Protected)：类的对象仅在类自身内部，或在子类自身内部可访问该特征 私有(Private)：类的对象仅在类自身内部可访问该特征 包(Package)或实现(Implementation)：类的对象仅在类自身内部、或在同一个包内的任意处，或在该类的子类自身内部可访问该特征 两点注意 对一个类的某特征，其自身类内部域是可不受限制的访问的。例如一个类的某方法可任意访问该类的别的方法或属性。“家贼难防，内部不设防”。 对于属性的包或实现的可见性，有些OOP语言中没有提供属性的覆盖改写机制（如C++和JAVA），因此没有这个概念。对.NET中的C#，就提供了这个机制。 一些面向对象的概念 封 装 （Encapsulation） 封装：把对象的属性和方法结合成一个独立的系统单位，并尽可能地隐藏对象的内部细节。 通常封装指的是对一个类的结构定义（类声明），将属性与操作绑定在一起。 后来一些OOP语言给出了接口机制。这样，接口成为一种封装机制。一个对象形成两个部分：接口部分和实现部分。采用针对接口编程的思维方式，对于用户来说，就只有接口部分是可见的，而实现部分是不可见的。 抽象（Abstraction） 继承/泛化(Inheritance/Generalization) IS-A关系 继承带来的赋值兼容性 Base=Derived “一个学生是一个人，但一个人不一定是一个学生”。 派生类对象是一个基类对象，但基类对象不一定是一个派生类对象。 以下合法： 对修改封闭，对扩展开放针对抽象编程 版本（1）的不好之处 “笨笨”的做法，硬编码，这样只能养两种类型的猪。当发生新的需求（比如增加新的猪品种），就不得不修改“工作”函数。 如果猪的品种越来越多，“工作”函数的判断逻辑就会越来越复杂，修改时需要理解的工作量直线上升，容易改错。 一句俗话：“改错是相对容易的，问题难在发现是何处错了”。“工作”函数代码过于冗长，不容易发现错误所在的地方。 针对抽象编程，以不变应万变设计 版本（2）能适应变化 虚构了猪这个抽象类，定义了“吃”这个纯虚函数。 当增加了猪的品种，定义该新猪品种类，实现其自己的“吃”函数。 不需要修改“工作”函数，代码具有适应变化的能力。其函数中只出现了抽象的基类，具体是哪种派生类的猪实例在吃，取决于传入的形参的具体类型。 两个思想原则 对修改封闭，对扩展开放：是面向对象思想基本原则之一。当面临需求变化时，不要试图去修改模块函数内部，或者因为其内部逻辑复杂修改代价高，或者因为无法拿到源码不能修改。而应在系统设计之初，就把容易变化的功能部分提取出来作为基类抽象类的一个或多个虚函数存在，每当变化来临，就增加新的派生类，扩展提供新的功能实现。 针对抽象不针对具象编程：是面向对象思想基本原则之一。编写功能函数时，不要硬编码，为使得函数具有适应变化的能力，函数传入的形参类型应使用基类类型。 单继承和多继承 单继承：子类只从一个父类继承 多继承：子类只从一个父类继承 “菱形”问题 “菱形”问题描述 子类的多个父类间也存在着直接或间接继承时，一个子类对象的实例化会造成祖先类构造函数的多次调用，从而对应有多份内存。产生一个子类对象是多个父类对象的悖论。 “菱形”问题的变型 菱形问题并非特例 在类的继承层次比较多时，往往为了获得某个类的某个方法代码而去继承它，就埋下了隐患。如果不是IS-A关系，就不要去继承，建议使用聚集HAS-A来达到同样的效果。 从多个父类继承时，并不清楚几个平行父类间是否有着继承关系。 解决菱形问题 对于第一种情况，不使用继承而改用聚合/聚集该需要复用其代码的类对象即可 对于第二种情况，多继承没有办法解决。毕竟，继承机制只是定义了对于扩展开放对修改封闭的OO特性，从客户应用的角度来说，客户端几乎没有办法知道它现在需要继承的父类之间，以及完成的继承树是怎么样的。 继承的小结 继承使得子类可以复用父类的功能函数。 动态绑定的特性使得父类的虚函