Section类图和对象图.pptVIP

* 违背LSP原则 Square类针对height、width添加了Rectangle所没有的附加的约束（即要求height=width），这样Square类（子类）不能完全替换Rectangle（父类） 违背了LSP原则 * 怎么办？ 在可能的情况下，由抽象类（接口）继承 * 解决方案 * DIP（依赖倒置原则，The Dependency Inversion Principle） 高层模块不应该依赖于低层模块。二者都应该依赖于抽象 抽象不应该依赖于细节。细节应该依赖于抽象 针对接口编程，不要针对实现编程 依赖倒置原则DIP * 传统的依赖关系 依赖的方向 * 符合DIP的系统 依赖的方向 依赖的方向 * * 接口分离原则ISP ISP（ The Interface Segregation Principle，接口隔离原则） 客户不应该依赖他们不用到的方法，只给每个客户它所需要的接口 为了避免“肥接口(fat interface)”，应当以一个类实现多个接口，而各客户仅仅获知必须的接口 * * 一个真实的例子: 某全文查找引擎的系统设计. 违反接口分离原则 * 探索器接口 索引生成器接口 搜索结果集接口 功能接口的划分： * 设计过程中注意的问题 遵守OO设计原则. 不同类中相似方法的名称应该相同. 遵守已有的约定俗成的习惯. 尽量减少消息模式的数目. 只要可能,使消息具有一致的模式, 以利于理解. 设计简单的类. 类的职责要明确, 不要在类中提供太多的服务, 应该从类名可以比较容易推断出用途. 泛化结构的深度要适当. 定义简单的方法. 一个方法内不要包含过多的功能. * 好的设计的变动轨迹: * 对象图 对象图表示地组对象及它们之间的关系. 是系统详细状态在某一时刻的快照, 表示复杂的类图的一个实例. 对象图的建模元素: 对象和链 对象图在UML建模中使用有限, 用于表达数据结构的示例, 了解系统在某个特定时刻的具体情况. * 对象图的表示法 对象名：由于对象是一个类的实例，因此其名称的格式是“对象名：类名”，这两个部分是可选的，但如果是包含了类名，则必须加上“：”，另外为了和类名区分，还必须加上下划线。 属性：由于对象是一个具体的事物，因此所有的属性值都已经确定，因此通常会在属性的后面列出其值。 * 对象图 类图 对象图 发现类 小王是一个爱书之人，家里各类书籍已过千册，而平时又时常有朋友外借，因此需要一个个人图书管理系统。该系统应该能够将书籍的基本信息按计算机类、非计算机类分别建档，实现按书名、作者、类别、出版社等关键字的组合查询功能。在使用该系统录入新书籍时系统会自动按规则生成书号，可以修改信息，但一经创建就不允许删除。该系统还应该能够对书籍的外借情况进行记录，可对外借情况列表打印。另外，还希望能够对书籍的购买金额、册数按特定时间周期进行统计 筛选备选类 “小王”、“人”、“家里”很明显是系统外的概念，无须对其建模； 而“个人图书管理系统”、“系统”指的就是将要开发的系统，即系统本身，也无须对其进行建模； 很明显“书籍”是一个很重要的类，而“书名”、“作者”、“类别”、“出版社”、“书号”则都是用来描述书籍的基本信息的，因此应该作为“书籍”类的属性处理，而“规则”是指书号的生成规则，而书号则是书籍的一个属性，因此“规则”可以作为编写“书籍”类构造函数的指南。 筛选备选类 “基本信息”则是书名、作者、类别等描述书籍的基本信息统称，“关键字”则是代表其中之一，因此无需对其建模 “功能”、“新书籍”、“信息”、“记录”都是在描述需求时使用到的一些相关词语，并不是问题域的本质，因此先可以将其淘汰掉； 筛选备选类 “计算机类”、“非计算机类”是该系统中图书的两大分类，因此应该对其建模，并改名为“计算机类书籍”和“非计算机类书籍”，以减少歧义； 筛选备选类 “外借情况”则是用来表示一次借阅行为，应该成为一个候选类，多个外借情况将组成“外借情况列表”，而外借情况中一个很重要的角色是“朋友”—借阅主体。虽然到本系统中并不需要建立“朋友”的资料库，但考虑到可能会需要列出某个朋友的借阅情况，因此还是将其列为候选类。为了能够更好地表述，将“外借情况”改名为“借阅记录”，而将“外借情况列表”改名为“借阅记录列表”； 筛选备选类 “购买金额”、“册数”都是统计的结果，都是一个数字，因此不用将其建模，而“特定时限”则是统计的范围，也无需将其建模；不过从这里的分析中，我们可以发现，在该需求描述中隐藏着一个关键类—书籍列表，也就是执行统计的主体。 得到候选类 在使用“名词动词法”寻找类的时候，很多团队会在此耗费大量的时间，特别是对于中大型项目，这样很容易迷失方向。其实在此主要的目的是对问题领域建立概要的了解，无需