正如牛顿三大定律在经典力学中的位置一样，“开-闭”原则（Open-Closed Principle）是面向对象的可复用设计（Object Oriented Design或OOD）的基石。其他设计原则（里氏代换原则、依赖倒转原则、合成/聚合复用原则、迪米特法则、接口隔离原则）是实现“开-闭”原则的手段和工具。
一、“开-闭”原则（Open-Closed Principle,OCP）
1.1“开-闭”原则的定义及优点
1）定义：一个软件实体应当对扩展开放，对修改关闭( Software entities should be open for extension,but closed for modification.)。即在设计一个模块的时候，应当使这个模块可以在不被修改的前提下被扩展。
2）满足“开-闭”原则的系统的优点
a)通过扩展已有的软件系统，可以提供新的行为，以满足对软件的新需求，使变化中的软件系统有一定的适应性和灵活性。
b)已有的软件模块，特别是最重要的抽象层模块不能再修改，这就使变化中的软件系统有一定的稳定性和延续性。
c)这样的系统同时满足了可复用性与可维护性。
1.2如何实现“开-闭”原则
在面向对象设计中，不允许更改的是系统的抽象层，而允许扩展的是系统的实现层。换言之，定义一个一劳永逸的抽象设计层，允许尽可能多的行为在实现层被实现。
解决问题关键在于抽象化，抽象化是面向对象设计的第一个核心本质。
对一个事物抽象化，实质上是在概括归纳总结它的本质。抽象让我们抓住最最重要的东西，从更高一层去思考。这降低了思考的复杂度，我们不用同时考虑那么多的东西。换言之，我们封装了事物的本质，看不到任何细节。
在面向对象编程中，通过抽象类及接口，规定了具体类的特征作为抽象层，相对稳定，不需更改，从而满足“对修改关闭”；而从抽象类导出的具体类可以改变系统的行为，从而满足“对扩展开放”。
对实体进行扩展时，不必改动软件的源代码或者二进制代码。关键在于抽象。
1.3对可变性的封装原则
“开-闭”原则也就是“对可变性的封装原则”（Principle of Encapsulation of Variation ，EVP）。即找到一个系统的可变因素，将之封装起来。换言之，在你的设计中什么可能会发生变化，应使之成为抽象层而封装，而不是什么会导致设计改变才封装。
“对可变性的封装原则”意味着：
a)一种可变性不应当散落在代码的许多角落，而应当被封装到一个对象里面。同一可变性的不同表象意味着同一个继承等级结构中的具体子类。因此，此处可以
期待继承关系的出现。继承是封装变化的方法，而不仅仅是从一般的对象生成特殊的对象。
b)一种可变性不应当与另一种可变性混合在一起。作者认为类图的继承结构如果超过两层，很可能意味着两种不同的可变性混合在了一起。
使用“可变性封装原则”来进行设计可以使系统遵守“开-闭”原则。
即使无法百分之百的做到“开-闭”原则，但朝这个方向努力，可以显著改善一个系统的结构。
二、里氏代换原则（Liskov Substitution Principle, LSP）
2.1概念
定义：如果对每一个类型为T1的对象O1，都有类型为T2 的对象O2，使得以T1定义的所有程序P在所有的对象O1都代换为O2时，程序P的行为没有变化，那么类型T2是类型T1的子类型。
即，一个软件实体如果使用的是一个基类的话，那么一定适用于其子类。而且它觉察不出基类对象和子类对象的区别。也就是说,在软件里面,把基类都替换成它的子类,程序的行为没有变化。
反过来的代换不成立，如果一个软件实体使用的是一个子类的话，那么它不一定适用于基类。
任何基类可以出现的地方，子类一定可以出现。
基于契约的设计、抽象出公共部分作为抽象基类的设计。
2.2里氏代换原则与“开-闭”原则的关系
实现“开-闭”原则的关键步骤是抽象化。基类与子类之间的继承关系就是抽象化的体现。因此里氏代换原则是对实现抽象化的具体步骤的规范。
违反里氏代换原则意味着违反了“开-闭”原则，反之未必。
三、依赖倒转原则（dependence inversion principle, DIP）
3.1概念
依赖倒转原则就是要依赖于抽象，不要依赖于实现。（Abstractions should not depend upon details. Details should depend upon abstractions.）要针对接口编程，不要针对实现编程。（Program to an interface, not an implementation.）也就是说应当使用接口和抽象类进行变量类型声明、参数类型声明、方法返还类型说明，以及数据类型的转换等。而不要用具体类进行变量的类型声明、参数类型声明、方法返还类型说明，以及数据类型的转换等。要保证做到这一点，一个具体类应当只实现接口和抽象类中声明过的方法，而不要给出多余的方法。
传统的过程性系统的设计办法倾向于使高层次的模块依赖于低层次的模块，抽象层次依赖于具体层次。倒转原则就是把这个错误的依赖关系倒转过来。
面向对象设计的重要原则是创建抽象化，并且从抽象化导出具体化，具体化给出不同的实现。继承关系就是一种从抽象化到具体化的导出。
抽象层包含的应该是应用系统的商务逻辑和宏观的、对整个系统来说重要的战略性决定，是必然性的体现。具体层次含有的是一些次要的与实现有关的算法和逻辑，以及战术性的决定，带有相当大的偶然性选择。具体层次的代码是经常变动的，不能避免出现错误。
从复用的角度来说，高层次的模块是应当复用的，而且是复用的重点，因为它含有一个应用系统最重要的宏观商务逻辑，是较为稳定的。而在传统的过程性设计中，复用则侧重于具体层次模块的复用。
依赖倒转原则则是对传统的过程性设计方法的“倒转”，是高层次模块复用及其可维护性的有效规范。
特例：对象的创建过程是违背“开—闭”原则以及依赖倒转原则的，但通过工厂模式，能很好地解决对象创建过程中的依赖倒转问题。
3.2关系
“开-闭”原则与依赖倒转原则是目标和手段的关系。如果说开闭原则是目标,依赖倒转原则是到达"开闭"原则的手段。如果要达到最好的"开闭"原则,就要尽量的遵守依赖倒转原则，依赖倒转原则是对"抽象化"的最好规范。
里氏代换原则是依赖倒转原则的基础，依赖倒转原则是里氏代换原则的重要补充。
3.3耦合（或者依赖）关系的种类：
零耦合（Nil Coupling）关系：两个类没有耦合关系
具体耦合（Concrete Coupling）关系：发生在两个具体的（可实例化的）类之间，经由一个类对另一个具体类的直接引用造成。
抽象耦合（Abstract Coupling）关系：发生在一个具体类和一个抽象类（或接口）之间，使两个必须发生关系的类之间存有最大的灵活性。
3.3.1如何把握耦合
我们应该尽可能的避免实现继承，原因如下：
1 失去灵活性，使用具体类会给底层的修改带来麻烦。
2 耦合问题，耦合是指两个实体相互依赖于对方的一个量度。程序员每天都在(有意识地或者无意识地)做出影响耦合的决定：类耦合、API耦合、应用程序耦合等等。在一个用扩展的继承实现系统中，派生类是非常紧密的与基类耦合，而且这种紧密的连接可能是被不期望的。如B extends A ，当B不全用A中的所有methods 时，这时候，B调用的方法可能会产生错误!
我们必须客观的评价耦合度，系统之间不可能总是松耦合的，那样肯定什么也做不了。
3.3.2我们决定耦合的程度的依据何在呢？
简单的说，就是根据需求的稳定性，来决定耦合的程度。对于稳定性高的需求，不容易发生变化的需求，我们完全可以把各类设计成紧耦合的(我们虽然讨论类之间的耦合度，但其实功能块、模块、包之间的耦合度也是一样的)，因为这样可以提高
效率，而且我们还可以使用一些更好的技术来提高效率或简化代码，例如c# 中的内部类技术。可是，如果需求极有可能变化，我们就需要充分的考虑类之间的耦合问题，我们可以想出各种各样的办法来降低耦合程度，但是归纳起来，不外乎增加抽象的层次来隔离不同的类，这个抽象层次可以是抽象的类、具体的类，也可以是接口，或是一组的类。我们可以用一句话来概括降低耦合度的思想："针对接口编程，而不是针对实现编程。
在我们进行编码的时候，都会留下我们的指纹，如public的多少，代码的格式等等。我们可以耦合度量评估重新构建代码的风险。因为重新构建实际上是维护编码的一种形式，维护中遇到的那些麻烦事在重新构建时同样会遇到。我们知道在重新构建之后，最常见的随机bug大部分都是不当耦合造成的。
如果不稳定因素越大，它的耦合度也就越大。
某类的不稳定因素=依赖的类个数/被依赖的类个数
依赖的类个数＝在编译此类的时被编译的其它类的个数总和
3.3.3怎样将大系统拆分成小系统
解决这个问题的一个思路是将许多类集合成一个更高层次的单位,形成一个高内聚、低耦合的类的集合，这是我们设计过程中应该着重考虑的问题！
耦合的目标是维护依赖的单向性，有时我们也会需要使用坏的耦合。在这种情况下，应当小心记录下原因，以帮助日后该代码的用户了解使用耦合真正的原因。
3.4怎样做到依赖倒转？
以抽象方式耦合是依赖倒转原则的关键。抽象耦合关系总要涉及具体类从抽象类继承，并且需要保证在任何引用到基类的地方都可以改换成其子类，因此，里氏代换原则是依赖倒转原则的基础。
在抽象层次上的耦合虽然有灵活性，但也带来了额外的复杂性，如果一个具体类发生变化的可能性非常小，那么抽象耦合能发挥的好处便十分有限，这时可以用具体耦合反而会更好。
层次化：所有结构良好的面向对象构架都具有清晰的层次定义，每个层次通过一个定义良好的、受控的接口向外提供一组内聚的服务。
依赖于抽象：建议不依赖于具体类，即程序中所有的依赖关系都应该终止于抽象类或者接口。尽量做到：
1、任何变量都不应该持有一个指向具体类的指针或者引用。
2、任何类都不应该从具体类派生。
3、任何方法都不应该覆写它的任何基类中的已经实现的方法。
3.5依赖倒转原则的优缺点
依赖倒转原则虽然很强大，但却最不容易实现。因为依赖倒转的缘故，对象的创建很可能要使用对象工厂，以避免对具体类的直接引用，此原则的使用可能还会导致产生大量的类，对不熟悉面向对象技术的工程师来说，维护这样的系统需要较好地理解面向对象设计。
依赖倒转原则假定所有的具体类都是会变化的，这也不总是正确。有一些具体类可能是相当稳定，不会变化的，使用这个具体类实例的应用完全可以依赖于这个具体类型，而不必为此创建一个抽象类型。
四、合成/聚合复用原则（Composite/Aggregate Reuse Principle或CARP）
4.1概念
定义：在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分；新的对象通过向这些对象的委派达到复用这些对象的目的。
应首先使用合成/聚合，合成/聚合则使系统灵活，其次才考虑继承，达到复用的目的。而使用继承时，要严格遵循里氏代换原则。有效地使用继承会有助于对问题的理解，降低复杂度，而滥用继承会增加系统构建、维护时的难度及系统的复杂度。
如果两个类是“Has-a”关系应使用合成、聚合，如果是“Is-a”关系可使用继承。"Is-A"是严格的分类学意义上定义，意思是一个类是另一个类的"一种"。而"Has-A"则不同，它表示某一个角色具有某一项责任。
4.2什么是合成？什么是聚合？
合成（Composition）和聚合（Aggregation）都是关联（Association）的特殊种类。
聚合表示整体和部分的关系，表示“拥有”。如奔驰S360汽车，对奔驰S360引擎、奔驰S360轮胎的关系是聚合关系，离开了奔驰S360汽车，引擎、轮胎就失去了存在的意义。在设计中, 聚合不应该频繁出现，这样会增大设计的耦合度。
合成则是一种更强的“拥有”，部分和整体的生命周期一样。合成的新的对象完全支配其组成部分，包括它们的创建和湮灭等。一个合成关系的成分对象是不能与另一个合成关系共享的。
换句话说，合成是值的聚合（Aggregation by Value），而一般说的聚合是引用的聚合（Aggregation by Reference）。
明白了合成和聚合关系，再来理解合成/聚合原则应该就清楚了，要避免在系统设计中出现，一个类的继承层次超过3层，则需考虑重构代码，或者重新设计结构。当然最好的办法就是考虑使用合成/聚合原则。
4.3通过合成/聚合的优缺点
优点：
1) 新对象存取成分对象的唯一方法是通过成分对象的接口。
2) 这种复用是黑箱复用，因为成分对象的内部细节是新对象所看不见的。
3) 这种复用支持包装。
4) 这种复用所需的依赖较少。
5) 每一个新的类可以将焦点集中在一个任务上。
6) 这种复用可以在运行时间内动态进行，新对象可以动态的引用与成分对象类型相同的对象。
7) 作为复用手段可以应用到几乎任何环境中去。
缺点:就是系统中会有较多的对象需要管理。
4.4通过继承来进行复用的优缺点
优点：
新的实现较为容易，因为超类的大部分功能可以通过继承的关系自动进入子类。
修改和扩展继承而来的实现较为容易。
缺点：
继承复用破坏包装，因为继承将超类的实现细节暴露给子类。由于超类的内部细节常常是对于子类透明的，所以这种复用是透明的复用，又称“白箱”复用。
如果超类发生改变，那么子类的实现也不得不发生改变。
从超类继承而来的实现是静态的，不可能在运行时间内发生改变，没有足够的灵活性。
继承只能在有限的环境中使用。
五、迪米特法则（Law of Demeter，LoD）
5.1概述
定义：一个软件实体应当尽可能少的与其他实体发生相互作用。
这样，当一个模块修改时，就会尽量少的影响其他的模块。扩展会相对容易。
这是对软件实体之间通信的限制。它要求限制软件实体之间通信的宽度和深度。
5.2迪米特法则的其他表述：
1）只与你直接的朋友们通信。
2）不要跟“陌生人”说话。
3）每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位。
5.3狭义的迪米特法则
如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中的一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。
朋友圈的确定
“朋友”条件：
1）当前对象本身（this）
2）以参量形式传入到当前对象方法中的对象
3）当前对象的实例变量直接引用的对象
4）当前对象的实例变量如果是一个聚集，那么聚集中的元素也都是朋友
5）当前对象所创建的对象
任何一个对象，如果满足上面的条件之一，就是当前对象的“朋友”；否则就是“陌生人”。
缺点：会在系统里造出大量的小方法，散落在系统的各个角落。
与依赖倒转原则互补使用
5.4狭义的迪米特法则的缺点：
在系统里造出大量的小方法，这些方法仅仅是传递间接的调用，与系统的商务逻辑无关。
遵循类之间的迪米特法则会是一个系统的局部设计简化，因为每一个局部都不会和远距离的对象有直接的关联。但是，这也会造成系统的不同模块之间的通信效率降低，也会使系统的不同模块之间不容易协调。
5.5迪米特法则与设计模式
门面（外观）模式和调停者（中介者）模式实际上就是迪米特法则的具体应用。
5.6广义的迪米特法则
迪米特法则的主要用意是控制信息的过载。在将迪米特法则运用到系统设计中时，要注意下面的几点：
1）在类的划分上，应当创建有弱耦合的类。
2）在类的结构设计上，每一个类都应当尽量降低成员的访问权限。
3）在类的设计上，只要有可能，一个类应当设计成不变类。
4）在对其他类的引用上，一个对象对其对象的引用应当降到最低。
5.7广义迪米特法则在类的设计上的体现
1）优先考虑将一个类设置成不变类
2）尽量降低一个类的访问权限
3）谨慎使用Serializable
4）尽量降低成员的访问权限
5）取代C Struct
迪米特法则又叫作最少知识原则（Least Knowledge Principle或简写为LKP），就是说一个对象应当对其他对象有尽可能少的了解。
5.8如何实现迪米特法则
迪米特法则的主要用意是控制信息的过载，在将其运用到系统设计中应注意以下几点：
1) 在类的划分上，应当创建有弱耦合的类。类之间的耦合越弱，就越有利于复用。
2) 在类的结构设计上，每一个类都应当尽量降低成员的访问权限。一个类不应当public自己的属性，而应当提供取值和赋值的方法让外界间接访问自己的属性。
3) 在类的设计上，只要有可能，一个类应当设计成不变类。
4) 在对其它对象的引用上，一个类对其它对象的引用应该降到最低。
六、接口隔离原则（interface separate principle, ISP）
6.1概念
接口隔离原则：使用多个专门的接口比使用单一的总接口要好。也就是说，一个类对另外一个类的依赖性应当是建立在最小的接口上。
这里的"接口"往往有两种不同的含义：一种是指一个类型所具有的方法特征的集合，仅仅是一种逻辑上的抽象；另外一种是指某种语言具体的"接口"定义，有严格的定义和结构。比如c# 语言里面的Interface结构。对于这两种不同的含义，ISP 的表达方式以及含义都有所不同。(上面说的一个类型，可以理解成一个类，我们定义了一个类，也就是定义了一种新的类型)
当我们把"接口"理解成一个类所提供的所有方法的特征集合的时候，这就是一种逻辑上的概念。接口的划分就直接带来类型的划分。这里，我们可以把接口理解成角色，一个接口就只是代表一个角色，每个角色都有它特定的一个接口，这里的这个原则可以叫做"角色隔离原则"。
如果把"接口"理解成狭义的特定语言的接口，那么ISP表达的意思是说，对不同的客户端，同一个角色提供宽窄不同的接口，也就是定制服务，个性化服务。就是仅仅提供客户端需要的行为，客户端不需要的行为则隐藏起来。
应当为客户端提供尽可能小的单独的接口，而不要提供大的总接口。
这也是对软件实体之间通信的限制。但它限制的只是通信的宽度，就是说通信要尽可能的窄。
遵循迪米特法则和接口隔离原则，会使一个软件系统功能扩展时，修改的压力不会传到别的对象那里。
6.2如何实现接口隔离原则
不应该强迫用户依赖于他们不用的方法。
1、利用委托分离接口。
2、利用多继承分离接口。
面向对象设计原则
单一职责原则--SRP 一、SRP简介（SRP--Single-Responsibility Principle）： 就一个类而言，应该只专注于做一件事和仅有一个引起它变化的原因。 所谓职责，我们可以理解他为功能，就是设计的这个类功能应该只有一个，而不是两个或更多。也可以理解为引用变化的原因，当你发现有两个变化会要求我们修改这个类，那么你就要考虑撤分这个类了。因为职责是变化的一个轴线，当需求变化时，该变化会反映类的职责的变化。“就像一个人身兼数职，而这些事情相互关联不大，，甚至有冲突，那他就无法很好的解决这些职责，应该分到不同的人身上去做才对。” 二、举例说明： 违反SRP原则代码: modem接口明显具有两个职责：连接管理和数据通讯； interface Modem { public void dial(string pno); public void hangup(); public void send(char c); public void recv(); } 如果应用程序变化影响连接函数，那么就需要重构： interface DataChannel { public void send(char c); public void recv(); } interface Connection {
public void dial(string pno); public void hangup(); } 三、SRP优点： 消除耦合，减小因需求变化引起代码僵化性臭味 四、使用SRP注意点： 1、一个合理的类，应该仅有一个引起它变化的原因，即单一职责； 2、在没有变化征兆的情况下应用SRP或其他原则是不明智的； 3、在需求实际发生变化时就应该应用SRP等原则来重构代码； 4、使用测试驱动开发会迫使我们在设计出现臭味之前分离不合理代码； 5、如果测试不能迫使职责分离，僵化性和脆弱性的臭味会变得很强烈，那就应该用Facade或Proxy模式对代码重构；
课程设计报告 课程名称面向对象程序设计 课题名称学生成绩管理系统 专业计算机科学与技术 班级计算机 1001 学号 01 姓名 指导教师李珍辉陈淑红李杰军 2011年 12 月 28 日
湖南工程学院 课程设计任务书 课程名称面向对象程序设计 课题学生成绩管理系统 专业班级计算机1001 学生姓名 学号 01 指导老师李珍辉陈淑红李杰军 审批 任务书下达日期 2011 年 11 月 15 日 任务完成日期 2011 年 12 月 28 日
一、设计内容与设计要求 1.课程设计目的： 面向对象程序设计课程设计是集中实践性环节之一，是学习完《面向对象程序设计》课程后进行的一次全面的综合练习。要求学生达到熟练掌握C++语言的基本知识和技能；基本掌握面向对象程序设计的思想和方法；能够利用所学的基本知识和技能，解决简单的面向对象程序设计问题，从而提高动手编程解决实际问题的能力。 2.课题题目 1）公司库存管理系统 2）高校学籍管理系统 3）高校工资管理系统 4）高校人事管理系统 5）通讯录程序设计 6）学生成绩管理系统 7) 图书管理系统 8）文本编辑器的设计与实现 9）学生考勤管理系统 10）公司人员管理系统 3．设计要求： ⑴设计课题题目：每位同学根据自己学号除以10所得的余数加1选择相 应题号的课题。随意换题者不记成绩。 ⑵根据自己对应的课题完成以下主要工作：①完成系统需求分析：包括 系统设计目的与意义；系统功能需求（系统流程图）；输入输出的要求。②完 成系统总体设计：包括系统功能分析；系统功能模块划分与设计（系统功能模 块图）。③完成系统详细设计：包括数据库需求分析；数据库概念结构设计（E －R图）；数据库逻辑结构设计；类层次图；界面设计与各功能模块实现。④系 统调试：调试出现的主要问题，编译语法错误及修改，重点是运行逻辑问题修 改和调整。⑤使用说明书及编程体会：说明如何使用你编写的程序，详细列出 每一步的操作步骤。⑥关键源程序（带注释）
课程设计报告书 课程名称面向对象程序设计 设计题目文本编辑器的设计与实现 专业班级 学号 姓名 指导教师 年月
目录 1 设计时间 (1) 2 设计目的 (1) 3设计任务 (1) 4 设计内容 (1) 4.1需求分析 (1) 4.2概要设计 (1) 4.2.1功能结构图 (1) 4.3详细设计 (2) 4.3.1流程图 (3) 4.4系统的功能实现 (4) 4.4.1类或包的加载 (5) 4.4.2设计一个主类，变量的定义 (5) 4.4.3文件操作功能的实现 (6) 4.5运行测试 (25) 4.5.1文本编辑器界面 (25) 4.5.2各功能菜单界面 (25) 5 总结与展望 (26) 参考文献 (26) 成绩评定 (27)
1 设计时间 2011年12月19日~2011年12月25日 2 设计目的 本次设计是学习完《java6程序设计》课程后进行的一次全面的综合练习，目的是加深对本学期课程的理解，通过设计文本编辑器并实现其功能来熟练掌握java语言基础，初步掌握软件开发的基本方法与技术将理论课程中学到的知识运用到实践中，实现有一定规模的Java应用。 3设计任务 本次设计的主要任务是文本编辑器的设计与实现，要求设计一个类似于Windows记事本(Notepad)的Java程序。可以打开、新建、保存一个文本文件；对选中的文本进行各种编辑操作（设置字体、字号、字型、对齐方式、背景、前景色、复制、粘贴、剪切、查找、替换等）；在文本中能够插入对象。 4 设计内容 4.1需求分析 现在网络上各种文本编辑器数不胜数，有EmEditor ，UEStudio ，GridinSoft Notepad ，Notepad++，win32pad ，SkimEdit，UniRed，xint 。功能也是应有尽有，有能改变字体的，有能改变文字颜色的。但是，这些软件又存在各种各样的瑕疵或问题：有的文件体积相对于一般文字编辑来说太大；有的功能太繁杂，使初级使用者一时难以掌握。仅从日常应用方面来说，一个文本编辑器只需一些简单实用的功能就够了。本程序设计就是依照这样一种使用需要设计了一个简单的文本编辑器程序。 4.2概要设计 4.2.1功能结构图
北京邮电大学200X-200X学年第一学期 《面向对象的设计方法与C++编程》期末考试试卷+扩展+复习题 试题一：填空题（没空一分，共20分） 请在括号内填入你认为正确的内容。 1.软件工程是指导（计算机软件）开发和维护的（工程学科）。 2.应用软件工程方法开发软件系统的根本目的是为了改善下述四项软件品质因素： 提高所开发的软件系统的（效率）； 降低所开发的软件系统的（成本）； 改善所开发的软件系统的（质量）； 缩短所开发的软件系统的（开发周期）。 3.抽象的对象模型由（属性）和（方法）两个部分构成。 4.一个消息必须具备的两个要素是（接受消息的对象标识）和（接受消息的对象的方 法标识）。 5.一个对象拥有另一个对象的（部分）或（全部）的属性和方法的关系则称为（继 承）关系。 6.失去（创建具体对象实例的（制造对象））能力的类成为抽象类。 7.一个类的属性不能出现对象拷贝则被称为（类属性）。 8.面向对象技术的三大特征是（封装）、（继承）和（多态）。 9.共生包容关系中的被包容类对象与包容类对象是（同时连带）生成的。 10.同时出现在两个具有关联关系的对象内的相同属性被称为（连接属性）。 课程复习--补充题： 1.软件的生存周期是一个软件产品从（定义）、（开发）、（使用）到（废弃）的时 间的总合。 2.C++语言中的静态成员函数是（类方法）的具体实现。 3.连接属性是（关联/链接）关系的两个对象内的属性。 4.边界类与（actor（角色））对呈一一对应关系。 5.复合聚合关系中的（聚合）类对象极其依赖（被聚合）类对象，在实现上往往具有 被同时（构造）的特征，因而具有极高的（耦合度）。 试题二：是非判断题（每题1分，共20分） 请在题后的括号内填入√（你认为正确时）或×（你认为错误时）。 1.消息必须含有返回信息。（错） 2.一个类必然具有生成对象的能力。（错）（抽象类不具备） 3.在包容关系中的被包容类也具有封装性。（对） 4.关联关系只是一个动作的抽象。（错） （表示两个类之间的联系，通过这种联系，一个类可以访问到另外一个类的属性和方法。） 5.一个类也可以接收消息。（对） 6.关联关系中的作用名标识了该关联关系的终点对象的恰当地位。（对）
程序设计说明书 1引言 1?1编写目的 程序设汁说明书提供用户与开发人员对开发软件的共同理解，使用户与开发单位就该系统的功能定义、环境需求达成共识，是今后各阶段设汁工作的基础和依据，也是本阶段评审和测试阶段确认与验收的依据。本需求分析的读者对象包括客户、业务人员需求分析人员、测试人员、用户文档编写人和项目管理人员。 本阶段已在系统的需求分析的基础上，对机票预左系统做概要设计。主要解决了实现该系统需求的程序模块设讣问题。包括如何把该系统划分成若干个模块、决定各个模块之间的接口、模块之间传递的信息，以及数据结构、模块结构的设汁等。在以下的概要设计报告中将对在本阶段中对系统所做的所有概要设计进行详细的说明。 在下一阶段的详细设计中，程序设计员可参考此概要设计报告，在概要设计对机票预定系统所做的模块结构设计的基础上，对系统进行详细设汁。在以后的软件测试以及软件维护阶段也可参考此说明书，以便于了解在概要设计过程中所完成的各模块设il?结构，或在修改时找出在本阶段设计的不足或错误。 预期的读者：系统管理员、机票预订管理员、订票旅客、程序员。 12背景 软件名称：机票预订系统 提出者：程序员 开发者：XXX o 用户：系统管理员、程序员。 运行该软件的计算站(中心)：Internet.航空公司、网上银行
2程序设计说明 2.1需求规定 1.管理员管理航班与打印机票活动图 (1) 管理员登陆界面管理航班信息与旅客信息。 (2) 管理员根据旅客信息安排航班。 (3) 管理员根据机票价格收费。 (4) 打印机票与账单。
根据上面的描述，管理员管理航班与打印机票活动图如图5-1所示。 ?活动起点 图2.1订票管理员管理航班与打印机票活动图 2 ?旅客订票与打印机票活动图 ⑴旅客登陆操作界面选择航班或山订票管理员安排航班。 (2) 选择航班后确认订票形象。 (3) 确认完毕缴费。 (4) 山管理员打印机票和账单。 根据上面的描述，旅客订票与打印机票活动图如图5-2所示。
面向对象系统的分析与设计》学习报告 面向对象系统的分析与设计课程是本专业的一门重要的专业课。通过本课程的学习，使我在已有的计算机软硬件基础知识、程序设计知识、数据库和网络通信知识的基础上系统掌握了面向对象系统的分析与设计方法和技术，并初步具备了针对特定环境下的应用问题进行信息系统开发（包括系统分析、设计与实现）的能力。现将学习情况作以下汇报。 一、面向对象概述 在 20 世纪 60 年代以前，软件开发者构造的软件系统大多都是较小的，且相对简单。编程语言及编程环境也相对简单，随着软件复杂性的增长，为了更好地维护代码，软件开发也需要方法来进行约束。传统的方法中，结构化方法和基于建模方法是典型的软件开发方法。结构化方法是结构化分析、结构化设计和结构化编程的总称。结构化方法的思想萌发于20世纪60年代，是在70年代由TomDe Macro和 Ed Yourdon 等人被系统地进出来。其目的在于，提供一个有序的机制，通过抽象来理解待开发的系统，试图产生结构良好的软件系统。但对于较复杂的系统而言，容易导致模块的低内聚和模块间的高耦合，从面使得系统缺乏灵活性和可维护性。基于建模方法在 20 世纪 70年代末提出，即Peter Chen的实体一一关系法与Ed Codd的关系数据库理论相结合提出的一种新的软件开发方法。其强调对信息实体建模，而不是对象建模。结构化方法和基于建模方法都没有较强地描述系统的动态行为的能力。随着计算机技术的飞速发展，计算
机管理系统应用的普及，企业信息化势在必行。传统开发方法结构化开发的软件存在很多问题，其有稳定性、可修改性和可重用性都比较差，生产效率低等缺陷，这是因为传统的软件开发是面向过程的。然而，用户需求的变化大部分是针对功能的，采用面向对象方法开发可以满足用户的需求，因为面向对象有以下优点：能够比较自然地反映现实事物，可重用性、可维护性和可扩展性比较强。 什么是面向对象呢？“面向对象”本身没有任何意义。“对象” 大概是英语中最普通的一个单词。它在字典中的定义是这样的。对象：能感觉到或能够被感觉到的东西。换句话说，对象可以是任何东西！ “面向”也没有任何特别的含义，它的定义是“指向” 。在这种定义下，“面向对象”被理解为形容词。因此，面向对象可以定义成这样，面向对象：指向你可以想到的任何东西。 毫无疑问，软件工业无法为“面向对象”下一个统一的定义。这种模糊性使得任何一个软件零售商都声称他们的商品是“面向对象” 的。 1 面向对象的基本概念 尽管权威人士对面向对象的概念没有达成一致的意见，但从程序设计方法的角度来看，面向对象是一种新的程序设计范型。其基本思想是使用对象、类、封装、继承、关联、聚合、消息、多态性等基本 概念来进行程序设计。 1.1 对象 (Object)
一、单一职责原则（ＳＲＰ） 就一个类而言，应该仅有一个引起它变化的原因。软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。测试驱动的开发实践常常会在设计出现臭味之前就迫使我们分离职责。 二、开闭原则（ＯＣＰ） 软件实体（类、模块、函数）应该是可扩展的，但是不可修改的。也就是说：对于扩展是开放的，对于更改是封闭的。怎样可能在不改动模块源代码的情况下去更改它的行为呢？怎样才能在无需对模块进行改动的情况下就改变它的功能呢？关键是抽象！因此在进行面向对象设计时要尽量考虑接口封装机制、抽象机制和多态技术。该原则同样适合于非面向对象设计的方法，是软件工程设计方法的重要原则之一。 三、替换原则（ＬＳＰ） 子类应当可以替换父类并出现在父类能够出现的任何地方。这个原则是Liskov于1987年提出的设计原则。它同样可以从Bertrand Meyer 的DBC (Design by Contract〔基于契约设计〕) 的概念推出。 四、依赖倒置原则（ＤＩＰ） １、高层模块不应该依赖于低层模块。二者都应该依赖于抽象。２、抽象不应该依赖于细节。细节应该依赖于抽象。在进行业务设计时，与特定业务有关的依赖关系应该尽量依赖接口和抽象类，而不是依赖于具体类。具体类只负责相关业务的实现，修改具体类不影响与特定业务有关的依赖关系。在结构化设计中，我们可以看到底层的模块是对高层抽象模块的实现（高层抽象模块通过调用底层模块），这说明，抽象的模块要依赖具体实现相关的模块，底层模块的具体实现发生变动时将会严重影响高层抽象的模块，显然这是结构化方法的一个"硬伤"。面向对象方法的依赖关系刚好相反，具体实现类依赖于抽象类和接口。 五、接口分离原则（ＩＳＰ） 采用多个与特定客户类有关的接口比采用一个通用的涵盖多个业务方法的接口要好。ISP原则是另外一个支持诸如COM等组件化的使能技术。缺少ISP，组件、类的可用性和移植性将大打折扣。这个原则的本质相当简单。如果你拥有一个针对多个客户的类，为每一个客户创建特定业务接口，然后使该客户类继承多个特定业务接口将比直接加载客户所需所有方法有效。 以上五个原则是面向对象中常常用到的原则。此外，除上述五原则外，还有一些常用的经验诸如类结构层次以三到四层为宜、类的职责明确化（一个类对应一个具体职责）等可供我们在进行面向对象设计参考。但就上面的几个原则看来，我们看到这些类在几何分布上呈现树型拓扑的关系，这是一种良好、开放式的线性关系、具有较低的设计复杂度。一般说来，在软件设计中我们应当尽量避免出现带有闭包、循环的设计关系，它们反映的是较大的耦合度和设计复杂化。 面向对象之代码复用规则 1、对接口编程 "对接口编程"是面向对象设计（OOD）的第一个基本原则。它的含义是：使用接口和同类型的组件通讯，即，对于所有完成相同功能的组件，应该抽象出一个接口，它们都实现该接口。具体到JAVA中，可以是接口，或者是抽象类，所有完成相同功能的组件都实现该接口，或者从该抽象类继承。尽量使用接口。接口只是对象打交道的入口，只有具有继承关系才使用抽象类。 2、优先使用对象组合，而不是类继承 "优先使用对象组合，而不是类继承"是面向对象设计的第二个原则。并不是说继承不重要，而是因为每个学习OOP的人都知道OO的基本特性之一就是继承，以至于继承已经被滥用了，而对象组合技术往往被忽视了。只有有现实生活中的父子关系才使用继承。 相关的设计模式有：Bridge、Composite、Decorator、Observer、Strategy等。 3、将可变的部分和不可变的部分分离 "将可变的部分和不可变的部分分离"是面向对象设计的第三个原则。如果使用继承的复用技术，我们
中北大学 面向对象程序设计实训 说明书 学院、系：软件学院 专业：软件工程 学生班级：13140A01 学生姓名：景贝贝学号：1314011438设计题目：电影院网上订票系统设计 起迄日期:2015年6月29日- 2015年7月10日指导教师:杨秋翔 2015 年7月8 日 实训任务书
实训任务书
一、需求分析 需求分析包括可行性分析、系统流程图和数据流图，数据字典。可行性分析包括技术可行性、经济可行性和操作可行性。 1.1 可行性分析 1.1.1 技术可行性 根据电影院提出的系统功能、性能及实现系统的各种约束条件，根据新系统目标来衡量所需的技术是否具备，本系统是一个数据库管理和查询的系统，现有的技术已较为成熟，硬件、软件的性能要求、环境条件等各项条件良好，估计利用现有技术条件应完全可以达到该系统的功能目标。同时，考虑给予的开发期限也较为充裕，预计系统是可以在规定期限内完成开发的。 由以上分析可知，影院售票系统的开发在技术上是可行的。 1.1.2 经济可行性 电影院具有信息化的处理设施，并且拥有支持本系统的应用平台。因此无需再投入资金购买其他设施。 系统的开发基于本人对程序开发的实践学习而来，电影院无需资金投入，并且软件开发过程投入的成本不高，因此开发经费完全可以
接受。 由以上分析可知，影院售票系统在经济上是可行的。 1.1.3 操作可行性 根据系统页面用户可以自动查询影片信息。还可浏览完影片信息以后操作订票、退票等功能。管理员也可以在后台添加、修改并删除影片信息，还可以管理注册用户信息和用户订票信息。 由以上分析可知本系统在操作上也是可行的。 1.2 系统流程图 首先未注册的用户要先注册，注册完了以后输入用户名和密码进入页面。根据网站上的影片信息用户可以选择自己喜欢的电影来订票。然后订票信息会自动存储到后台订票信息数据当中。 本系统的具体流程为如图所示。
华北电力大学科技学院 实验报告 实验名称图书馆管理系统的分析与设计课程名称面向对象技术 专业班级：学生姓名： 学号：成绩： 指导教师：实验日期：
一、图书管理系统需求描述 图书馆里有多种书目，每种书有多个副本，每个副本有唯一的编号。每本图书借阅期限为60天，超期罚款，按天计算，每天0.1元。 每个借阅者在系统中建立一个账户，并发放借阅证，账户中有用户名、证号、单位、存的现金数额，用于超期罚款，用户可以续费。 持借阅证的用户可以借书、还书，但这些操作要通过图书馆馆员来实现，每个借阅者可借10本书。每次借阅会将特定的借阅者和书籍副本联系起来。 图书管理员还负责图书的书目管理，书籍副本管理，借阅者管理。如果借阅证丢失，借阅证持有者应到图书馆前台挂失。 借阅证持有者可以预约图书，最多可预约3本（可以设定预约有效的期限），并在图书到达后得到电话通知，图书馆为其保留图书，3日内有效。还可以取消预约。 二、需求分析 系统的功能需求主要包括以下几个方面： 1.这是一个图书馆管理系统。 2.借阅者需预先建立一个账户（账户中有用户名、证号、单位、存的现金数额），并 领取借阅证，借阅者可以续费。 3.各种书目需预先注册。每种书目有多个副本且每个副本有唯一的编号。 3.借阅者能够通过图书馆馆员借书、还书（每个借阅者可借10本书），每次借阅或 归还都更新数据库信息。 4.借阅者可以通过网络查询书籍信息。 5.借阅者可以预约图书。当他所预约的图书归还或购进时，就通知预定人。图书馆为 其保留3日预约书籍。当预定某书的借书者借阅该书后，系统取消预约。 6.如果借阅者还书超过期限（60天），需扣款，按天计算，每天0.1元。 7.图书馆馆员在软件系统的支持下处理借阅者的借书和还书请求。 8.系统管理员可以对系统的数据进行维护，如增加、删除和更新书目，增加和删除书 籍，增加、删除和更新借阅者帐户，挂失借阅证等。 7.系统能够运行在流行的技术环境中，并应有一个良好的人机交互图形用户界面。 8.系统容易扩展新功能。 系统将通过计算机来处理图书、副本、借阅者和借书。借阅者要求借书，出示借阅证，查询该借阅者提供的借阅证是否满足借书要求。如果满足，给出要借图书的名称，系统查找所借的图书是否存在副本，如果有，则办理借书手续(登记借阅信息)。 图书是存放在图书馆中的书的名称，副本是一个图书的具体实例。一个图书可能有多个副本，一个副本一定会对应一个图书。一次借阅必须记录一个图书的副本和一个借阅证信息。一个副本可以被借阅，也可以不被借阅。一个借阅证可以借多本书，也可以
UML面向对象分析与设计 大作业 前言 “UML面向对象分析与设计”是计算机专业和软件工程等相关专业的一门重要课程，也是其他理工科专业的热门选修课程。“程序设计语言”、“计算机网络”、“数据库原理”和“数据机构”等是它的前导课程，学好本课程对学生毕业后从事软件开发有着极为重要的作用。 要学好这门课，仅仅通过课堂教学或自学掌握理论知识是远远不够的，还必须加强实践。特在学期末引入uml的综合分析与设计，从实际项目出发，使学生学会运用软件工程基本理论知识，UML建模语言和rose建模环境，去解决软件开发中的实际问题，达到学以致用的目的。
面向对象软件开发技术 项目的引入及需求 简易教学管理系统的分析、设计与实现 一、设计的目的 1.初步了解UML语言的概念、结构、语义与表示方法； 2.掌握UML建模工具Rational Rose的使用方法； 3.给出某个简单系统的模型，能够熟练地使用Rose工具表达； 二、设计理论基础 1. 面向对象的程序设计C++或JAVA程序设计课程； 2.数据结构或算法课程 2.SQLServer或mysql数据库系统； 3. 熟悉传统软件工程以及软件测试技术。 三、设计内容与步骤 需求陈述：简易教学管理系统主要提供两个方面的服务： 选课管理，负责新学期的课程选课注册。 成绩管理，负责学生成绩管理。 （1）简易教学管理系统---选课管理应提供的服务如下： 1.录入与生成新学期课程表 教学管理人员在新学期开学前录入新学期的课程，打印将开设的课程目录表，供师 生参考选择。如果某门课实际选课的学生少于10人，则停开该课程，把该课程从 课程表中删除；如某课程选课学生多于60人，则停止选课。 2.学生选课注册 新学期开始前一周为学生选课注册时间，在此期间学生可以选课注册，并且允许改 变或取消注册申请。 每个学生选课可不允许超过4门，每门课最多允许60名学生选课注册。 3.查询 可以查询课程信息、学生选课信息和学生、教师信息。
第八章面向对象的设计方法 本章采用基于UML的面向对象设计方法的将分析模型转换为设计模型。如第五章所述，面向对象的分析模型主要由顶层架构图、用例与用例图、领域概念模型构成；设计模型则包含以包图表示的软件体系结构图、以交互图表示的用例实现图、完整精确的类图、针对复杂对象的状态图和用以描述流程化处理过程的活动图等。为完成这一转换过程，设计人员必须处理以下任务： （1）针对分析模型中的用例，设计实现方案。实现方案用 UML交互图表示。 （2）设计技术支撑设施。在大型软件项目中，往往需要一些技术支撑设施来帮助业务需求层面的类或子系统完成其功能。这些设施本身并非业务需求的一部分，但却为多种业务需求的实现提供公共服务。例如，数据的持久存储服务、安全控制服务和远程访问服务等。在面向对象设计中，需要研究这些技术支撑设施的实现方式以及它们与业务需求层面的类及子系统之间的关系。 （3）设计用户界面。 （4）针对分析模型中的领域概念模型以及第（2）、（3）两个步骤引进的新类，完整、精确地确定每个类的属性和操作，并完整地标示类之间的关系。此外，为了实现软件重用和强内聚、松耦合等软件设计原则，还可以对前面形成的类图进行各种微调，最终形成足以构成面向对象程序
设计的基础和依据的详尽类图。 面向对象的软件设计过程如图8-1-1所示。 图 8-1-1 面向对象的软件设计过程 第一节设计用例实现方案 UML 的交互图（顺序图、协作图）适于用例实现方案的表示。因此，本节首先介绍交互图的语言机制，然后探讨用例实现方案的设计方法。该设计方法包含如下3个步骤： （1）提取边界类、实体类和控制类； （2）构造交互图； （3）根据交互图精华类图。 一、顺序图 顺序图用来描述对象之间动态的交互关系，着重表现对象间消息传递的时间顺序。在顺序图中，参与交互的对象位于顶端的水平轴上，垂直轴表示时间，时间推移的方向是自上而下的。顺序图中的对象一般以“对象
设计说明 目录 1 概述 ..................... 错误!未定义书签。 编写目的 .......... 错误!未定义书签。 参考资料 .......... 错误!未定义书签。 术语和缩写词* .错误!未定义书签。 2 需求概述.............. 错误!未定义书签。 3 结构设计.............. 错误!未定义书签。 总体设计 .......... 错误!未定义书签。 功能分配 .......... 错误!未定义书签。 接口设计 .......... 错误!未定义书签。 数据结构设计... 错误!未定义书签。 公共数据结构设计错误!未定 义书签。 数据库设计错误!未定义书签。 数据结构同程序的关系*错误! 未定义书签。 出错处理设计* .错误!未定义书签。 其它* ................ 错误!未定义书签。 4 类的设计.............. 错误!未定义书签。 类1设计 .......... 错误!未定义书签。 功能说明... 错误!未定义书签。
属性说明... 错误!未定义书签。 公有方法说明错误!未定义书 签。 私有方法说明错误!未定义书 签。 类2设计 .......... 错误!未定义书签。 功能说明... 错误!未定义书签。 属性说明... 错误!未定义书签。 公有方法说明错误!未定义书 签。 私有方法说明错误!未定义书 签。 5 用例实现的设计 .. 错误!未定义书签。 用例1设计 ...... 错误!未定义书签。 功能说明... 错误!未定义书签。 界面设计... 错误!未定义书签。 交互设计... 错误!未定义书签。 用例2设计 ...... 错误!未定义书签。 功能说明... 错误!未定义书签。 界面设计... 错误!未定义书签。 交互设计... 错误!未定义书签。
面向对象分析与及设计习题及答案 一、单项选择题 1.到20世纪末，面向对象软件工程已经逐渐发展成熟，特别是（D）的 形成和广泛使用，采用面向对象分析与编程的软件开发方法已成为软件开发的主流方法。 A. Simula67语言 B. Smalltalk语言 C. Java语言 D. 统一建模语言(UML)的标准 2. 面向对象的运动产生了多种面向对象的语言, 其中（C）是一种混合性面向对象语言, 既支持面向过程的程序设计方法，又支持面向对象的程序设计方法，有广泛应用的基础和丰富开发环境的支持，因而使面向对象的程序设计能得到很快普及。 A. Smalltalk B. Eiffel C. C++ D. Java 3．下列不属于面向对象技术的基本特征的是（B）。 A. 封装性 B. 模块性 C. 多态性 D. 继承性 4. 面向对象程序设计将描述事物的数据与(C) 封装在一起,作为一个相互依存、不可分割的整体来处理。 A. 信息 B. 数据隐藏 C. 对数据的操作 D. 数据抽象 5. 关于面向对象方法的优点，下列不正确的叙述是（C）。 A. 与人类习惯的思维方法比较一致 B. 可重用性好 C. 以数据操作为中心 D.可维护性好 6. （D）是从用户使用系统的角度描述系统功能的图形表达方法。 A. 类图 B. 对象图 C. 序列图 D. 用例图 7. (C) 是表达系统类及其相互联系的图示,它是面向对象设计的核心，建立状态图、协作图 和其他图的基础。 A．对象图 B. 组件图 C. 类图 D. 配置图 8.（D）描述了一组交互对象间的动态协作关系，它表示完成某项行为的对象和这些对象之 间传递消息的时间顺序。 A．对象图 B. 协作图 C. 状态图 D. 序列图 9.（D）就是用于表示构成分布式系统的节点集和节点之间的联系的图示，它可以表示系统 中软件和硬件的物理架构。 A. 组件图 B. 协作图 C. 状态图 D. 配置图 10. 使用UML进行关系数据库的（B）时，需要设计出表达持久数据的实体类及其联系，并把它们映射成为关系数据库表（Table)、视图(View)等。 A. 业务Use Case模型设计 B. 逻辑数据模型设计 C. 物理数据模型设计 C. 物理实现设计 11.一个设计得好的OO系统具有（B） A. 低内聚、低耦合的特征 B. 高内聚、低耦合的特征 C. 高内聚、高耦合的特征 D. 低内聚、高耦合的特征 12.下面（）不是UML的基本构成元素。（A） A. 控制语言 B. 基本构造块 C. 规则 D. 公共机制
1 第06章面向对象的设计原则Object-Oriented Design Principles -1- 2 -2- 学习路线图 OO UML OOP DP … Case-Study … 学习路线图 : : …… …… …… (1) 2 34 5 6 7 8 9 10 3从问题开始！ ?长方形与正方形 –假如我们有一个类：长方形（Rectangle） –我们需要一个新的类，正方形（Square） –问：可否直接继承长方形？ 没问题，因为数学上正方形就是长方形的子类！height : int width : int getHeight() : int getWidth() : int setHeight(h : setWidth(w : int) setHeight(h : int) setWidth(w : int)
7-7--7-面向对象的设计原则 ?面向对象的设计原则 –是面向对象设计的基本指导思想–是评价面向对象设计的价值观体系–是设计模式的出发点和归宿 ?面向对象的设计原则是构造高质量软件的出发点 8 -8--8- 设计目标 ?构造出高质量软件，以保持系统稳定?设计目标 –可扩展性（Extensibility ）–灵活性（Flexibility ）–可插入性（Pluggability ）– …… 9-9--9- 设计质量：培养灵敏的嗅觉 ?糟糕的设计总是散发出臭味，让人不悦 –判断一个设计的好坏，主观上能否让你的合作方感到心情愉悦，是最直观的标准 ?设计开发人员要培养嗅觉，当你看到UML 图或者代码，感到杂乱、繁琐、郁闷的时候，你可能正面对一个糟糕的设计 ?这种嗅觉是在实践开发中培养起来的，而面向对象设计原则对此加以归纳和总结 10 -10--10- 设计质量：坏的设计 ?什么是坏的设计？ –僵硬性（Rigidity ）：刚性，难以扩展–脆弱性（Fragility ）：易碎，难以修改 –牢固性（Immobility ）：无法分解成可移植的组件 –不必要的复杂性（Needless Repetition ）：Ctrl C + Ctrl V –晦涩性（Opacity ）：不透明，很难看清设计者的真实意图 11-11--11- 设计质量：好的设计 ?什么是好的设计？ –容易理解 –容易修改和扩展–容易复用 –容易实现与应用 – 简单、紧凑、经济适用 ?让人工作起来心情愉快的设计 ?设计原则是提高设计质量的基本原则 12 -12--12- 面向对象的基本设计原则 ?LSP ：Liskov 替换原则 –The Liskov Substitution Principle ?OCP ：开放-封闭原则 –The Open-Close Principle ?SRP ：单一职责原则 –The Single Responsibility Principle ?ISP ：接口隔离原则 –The Interface Segregation Principle ?DIP ：依赖倒置原则 –The Dependency Inversion Principle ?……
1、什么面向对象？ 面向对象不仅是以些具体的软件开发技术与策略，而且以一套关于如何看待软件系统与现实世界的关系，以什么观点来研究问题并进行求解，以及如何进行系统构造的软件方法学。 2、软件开发方法学的基本方法有哪些？ 1）软件工程和瀑布方法学2）新方法学：螺旋式、迭代式、递增式、合并式3）面向对象方法学：UML、RUP、XP 3、为什么需要OOA、OOD。 OOA就是运用面向对象的方法进行需求分析，OOA加强了对问题域和系统责任的理解，有利于人员之间的交流，对需求变化的适应性较强，很好的支持软件复用。 OOD就是运用面向对象的方法进行系统设计，OOD．符合人们习惯的思维方法，便于分解大型的复杂多变的问题；易于软件的维护和功能的增减；可重用性好；与可视化技术相结合，改善了工作界面。 4、从概念层次、规格层次、实现层次三个角度如何理解对象的概念？ 从概念层次来看，一个对象就是一系列的责任； 从规格层次来看，一个对象是一系列可以被其他对象或该对象自己调用的方法；从实现层次来看，一个对象是一些代码和数据。 5、如何绘制类图和对象图？简述其步骤。 类图绘制：1发现类，找到备选类，确定候选类2关联分析，确定关联关系，多重性分析3职责分析4限定与修改，导航性分析，约束，限定符; 对象图绘制：1发现类和对象2对其细化，分析，确定关系。 6、简述重定义方法与重载的区别。 重定义：1参数列表必须完全与被重写的方法相同2返回类型必须一直域被重写的方法的类型相同3访问修饰符的限制一定要大于被重写方法的访问修饰符4重写方法一定不能抛出新的检查异常或者比被重写方法申明更加宽泛的检查性异常：重载：1必须有不同参数列表2可以有不同的返回类型，只要参数列表不同即可3可有不同访问修饰符4可抛出不同的异常。 7.简述抽象方法与虚方法的联系与区别 虚方法有一个实现部分可以为子类实现有共同的方法，并为派生提供了覆盖该方法的选，抽象方法只是强制派生覆盖方法；抽象方法只能在抽象类中声明，而虚方法不是；抽象方法不能声明方法实体，虚方法可以；包含抽象方法的类不能实例化，但虚方法可以。 8、简述使用继承的规则。 1)、不要过度使用；2)、子类应是超类的一个类型；3)、子类应是超类的扩展； 4)、尽量少从具体类继承，最好继承接或抽象类。
实验报告面向对象的分析设计实现—图书管理系统 一.需求分析 1.1系统需求描述 一般图书馆管理系统主要用于对图书馆日常工作的管理，主要任务是用计算机对读者、图书等各种信息进行日常管理，如查询、修改、增加、删除、图书借阅和归还的管理等。本系统实现了图书馆的信息化管理，完成了图书馆管理系统的基本功能。 一般图书馆管理系统主要包括用户登录子系统、用户管理子系统、图书管理子系统、图书借阅与归还、图书和用户信息查询子系统四个部分，各部分主要功能如下： 用户登录子系统：用于数据库的连接，主界面的设计和不同身份用户的登录管理。 用户管理子系统：用于用户信息的管理，如用户添加、用户信息修改、用户删除。 图书管理子系统：用于图书信息的管理，如新书入库、图书信息修改、图书信息删除。 图书借阅与归还子系统：用于用户借阅和归还图书。 图书和用户信息查询:图书和用户信息的查询。 1.2系统功能结构图
图 1.1 图书管理系统分析系统流程图 1.3 系统解决方案 以上述一般的图书管理系统分析为构思原型。为简化系统，忽略掉其他复杂琐碎的功能需求，仅保留图书信息的录入、修改和读者借、续借、还的功能。读者与管理员通过界面对象调用控制类对象，控制对象进行各种操作并把信息写入数据库。 二.系统设计 2.1 系统E-R图 图 1.2 用户实体图
图1.3 书籍实体图 图 1.4 实体属性图 2.2数据库表结构 表2.1 图书信息表
表2.2 用户借阅表 表2.3用户信息表 2.3用例文档 本系统共设置四个活动者。分别是TT_People、TT_Registrar、TT_Reader 和TT_Database。其中TT_People泛指与系统发生关系的人；TT_Registrar为系统管理员，负责添加、修改图书信息；TT_Reader为所有读者，读者可能发生借书、续借、还书的行为；TT_Database为存储各种信息的数据库对象。另：考虑到现实图书馆中还存在“图书馆管理员”这一角色，但其所起的作用仅为代替读者完成各种系统操作，故没有设置此活动者。 系统中共有五个用例。TT_Addinfo、TT_Modifyinfo、TT_Borrow、TT_Renew 和TT_Return。TT_Addinfo表示管理员添加图书信息；TT_Modifyinfo表示修改图书信息；TT_Borrow表示读者借阅图书；TT_Renew表示读者续借图书；TT_Return表示读者归还图书。
?1、面向对象方法的基本观点： ?Coad-Y ourdon认为：面向对象=对象+类+继承+通信。 ?2、面向对象方法的特点包括： ?（1）、符合人们对客观世界的认识规律； ?（2）、对需求变化具有很强的适应性； ?（3）、支持软件复用； ?（4）、可维护性好。 ?3、对象、类、封装、继承、消息、多态性的基本概念。 对象是客观世界中具有可区分性的、能够唯一标识的逻辑单元，是现实世界中的一个事物（站在计算机技术角度，即对事物的模拟）。 类是一组具有相同属性和相同操作的对象的集合。 封装是把对象的属性和操作结合在一起，组成一个独立的单元。 继承是指子类（派生类、特化类）自动拥有其父类（基类、泛化类、超类）的全部属性和操作，即一个类可以定义为另一个更一般的类的特殊情况。 消息是对象之间采用消息传递来发生相互作用—互相联系、互发消息、响应消息、协同工作，进而实现系统的各项服务功能。 多态性是一种方法，使在多个类中可以定义同一个操作或属性名，并在每一个类中有不同的实现。 ?4、面向对象系统开发过程。 ?5、运用名词词组法来定义类（对象）： ?例：音像商店出租/出售业务信息系统中的类的确定。 ?总目标：?A．提供及时培训。?B．实施的系统必须友好，易学易用。?C．实施的系统必须考虑安全问题。
?具体目标： ?1.1.1 提供一个自动系统协助顾客出售/出租结帐。 ?2.1.1 提供和维护一个自动的会员数据库。?a. 按要求提供最新会员信息。? b. 有添加、改变、删除会员信息的能力。 2.1.2 提供会员信息报表（但不限于）?a. 最少光顾的会员。?b. 最经常光顾的会员。?c. 有问题会员（欠钱，出租过期）? 4.1.1 提供、维护出售和出租项的库存数据库。?a. 按要求提供最新库存信息?b. 有添加、改变、删除库存信息（出售和出租）的能力 4.1.2 提供库存信息报表（但不限于）?a. 最不受欢迎的出租项?b. 最受欢迎的出租项?c. 过期的出租项?d. 出售和出租项的“订购”产品（采购报表） 5.1.1 提供出售报表（但不限于）?a. 用产品码表示的一段时间（天、星期、月）内销售情况?b. 用产品码表示的一段时间（天、星期、月）内出租情况相应的侯选对象清单为：安全问题、自动系统、顾客出售/出租结帐、会员数据库、会员信息、会员信息报表、库存数据库、出售和出租项、库存信息、库存信息报表、采购报表、出售报表。 ?6、对多值属性的处理方法：用部分-整体方法。 例：发票/发票行 第2章统一建模语言UML 1、UML描述的软件基本模型：用例视图、逻辑视图、构件视图、进程视图、 部署视图 2、UML的基本符号。 3、RUP项目开发过程的特征：用例驱动的系统、以体系结构为中心、螺旋 上升式的开发过程、以质量控制和风险管理为保障措施。
日历记事本 1.课程设计目的 通过此次课程设计，巩固所学Java语言基本知识，增进Java语言编辑基本功，掌握JDK、Editplus、Eclipse、JCreator等开发工具的运用，拓宽常用类库的应用。使我们通过该教学环节与手段，把所学课程及相关知识加以融会贯通，全面掌握Java语言的编程思想及面向对象程序设计的方法，为今后从事实际工作打下坚实的基础。 本课程设计设计GUI界面的日历记事本，系统将日历和记事本结合在一起，可以方便的保存、查看日志，即在任何日期记载下有关容或查看某个日期记载的容。 2.设计方案论证 2.1设计思路 2.1.1 本系统界面的左侧是日历和一幅图像。该日历可以按年前后翻动，用鼠标左键单击“上年”按钮，可将当前日历的年份减一；用鼠标左键单击“下年”按钮，可将当前日历的年份加一。该日历还可以在某年按月前后翻动，用鼠标单击“上月”按钮，可将当前日历的月份减一；用鼠标单击“下月”按钮，可将当前日历的月份增一。 2.1.2 系统界面的右侧是记事本和一个时钟。用鼠标单击日历上的日期，就可以通过该记事本编辑有关日志，并将日志保存到一个文件。该文件的名字是由当前日期组成的字符序列。用户可以查看、删除某个日期的日志，也可以继续向某个日志添加新的容。2.1.3 当某个日期有日志时，显示该日期的外观上就会出现“有”标记，表明这个日期有日志；当用户删除某个日期的日志后，该日期的外观上的“有” 标记就会消失。 2.2设计方法 在设计日历记事本时，需要编写6个Java源文件：CalendarWindow.java、CalendarPad.java、NotePad.java、CalendarImage.java 、Clock.java和CalendarMessage.java。 日历记事本除了需要编写的上述6个Java源文件所给出的类外，还需要Java系统提供的一些重要的类，如JTextField、JTextArea和File类。 2.2.1 CalendarWindow.java 主类