Java面向对象的总结和综合练习_第1页
Java面向对象的总结和综合练习_第2页
Java面向对象的总结和综合练习_第3页
Java面向对象的总结和综合练习_第4页
Java面向对象的总结和综合练习_第5页
已阅读5页,还剩9页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、Java面向对象的总结和综合案例练习一、难点突破下表列出本阶段的难点,如果某个难点没完全掌握,请写下你感到疑惑的地方,然后通过复习教材,从网上查找资料、与同学探讨、向老师请教等途径突破这些难点。如果你掌握了这个难点,请在是否掌握一栏中打。这些技能是学习后面技能的基础,所以一定要在继续学习前突破。如果你还有其他难点,也请填写在表中。表1 本学习阶段难点记录表难 点感到疑惑的地方突破方法是否掌握类的定义对象的创建this、super关键字的使用static、final关键字的使用面向对象设计的过程使用权限修饰符进行类的封装继承关系下构造方法的执行利用多态减少代码量,提高代码的可扩展性和可维护性接口

2、与抽象类的异同包的概念和定义包装类的常见用法二、知识点梳理2.1 面向对象的封装2.2 类的定义2.3 对象的引用2.4 static的应用2.5 类的继承2.6 Java的多态2.7 Java的接口2.8 final和abstract的应用2.9 包装类2.10 包的定义及应用2.11 Object类2.12 内部类三、综合练习3.1 任务描述本次综合练习的任务是:以面向对象思想设计动物乐园系统。动物乐园有猫、猴子等成员,还可能增加新成员。猫和猴子都有自己的名字,都有腿,但腿的条数不同,都会发出叫声,猫的叫声是喵喵喵,猴子的叫声是吼吼吼,要求进行面向对象设计,画出类图并写出代码。练习的难度不

3、高,关键是明确面向对象设计是一个不断优化的过程,是为了有效解决业务问题。3.2 上机练习阶段1:设计猫和猴子的类设计,画出类图并写出代码需求说明以面向对象思想设计猫和猴子的类结构,画出类图并写出代码。实现思路根据任务表述,可以设计出两个类,猫类Cat和猴子类Monkey,它们均有名字、腿的条数属性,均具有吼叫的方法,由此可以提取出父类-Animal类,进行代码重用,让Cat、Monkey均继承Animal类。但是Animal类不是一种具体的动物,创建Animal对象没有实际意义,Animal对象也无法真正发出叫声,且子类必须重写吼叫的方法,所以可以将Animal类设计成抽象类,把吼叫的方法设计

4、成抽象方法。阶段2:增加新成员海豚,重新设计类结构需求说明在动物乐园中增加一个新成员海豚Dolphin,海豚的叫声是海豚音实现思路让海豚直接继承Animal类可以么?海豚没有腿,所以不能继承Animal类,但海豚又确实是一种动物,所以,只有对Animal类进行重新设计,去掉腿的条数的属性。但是问题又来了,如何再约束Cat和Monkey类呢?可以采用如下思路:创建Terrestrial(陆生的)接口,声明getLegNum()方法(获取腿的数量),然后让Cat和Monkey在继承Animal类的同时实现Terrestrial接口。根据以上的描述画出类图,并写出Java代码。阶段3:输出各种动物如

5、何叫需求说明在阶段2编写的Java代码的基础上,分别创建Cat、Duck和Dolphin对象并放到一个数组中,对数组进行遍历输出各种动物如何叫,运行结果如图所示。要求:创建Animal类型的数组存放各种动物对象,利用多态实现功能。阶段4:输出各种动物腿的数量需求说明在阶段3编写的Java代码的基础上,分别创建Cat、Duck和Dolphin对象并放到一个数组中,对数组进行遍历输出各种动物动物腿的条数,运行结果如图所示。提示:数组中有Dolphin对象元素,但海豚没有腿,输出是应判断各个对象是否实现了Terrestrial接口,可以使用instanceof进行判断。if(animali inst

6、anceof Terrestrial) /输出腿的条数四、常用英文单词class、object、static、final、private、public、protected、overload、constructor、encapsulationinheritance、extend、super、override、abstract、polymorphism、instance、elapse、parameter、blockClassCastException、upcasting、downcasting、interface、implement、wrapper、NullPointerException、par

7、seInt、valueOf、InnerClass、五、深入学习学习主题:面向对象的设计原则5.1 类和类之间的依赖、关联、聚合、组合关系1. 继承关系 继承指的是一个类(称为子类、子接口)继承另外的一个类(称为父类、父接口)的功能,并可以增加它自己的新功能的能力。在Java中继承关系通过关键字extends明确标识,在设计时一般没有争议性。在UML类图设计中,继承用一条带空心三角箭头的实线表示,从子类指向父类,或者子接口指向父接口。 2. 实现关系 实现指的是一个class类实现interface接口(可以是多个)的功能,实现是类与接口之间最常见的关系。在Java中此类关系通过关键字imple

8、ments明确标识,在设计时一般没有争议性。在UML类图设计中,实现用一条带空心三角箭头的虚线表示,从类指向实现的接口。 3. 依赖关系 简单的理解,依赖就是一个类A使用到了另一个类B,而这种使用关系是具有偶然性的、临时性的、非常弱的,但是类B的变化会影响到类A。比如某人要过河,需要借用一条船,此时人与船之间的关系就是依赖。表现在代码层面,为类B作为参数被类A在某个method方法中使用。在UML类图设计中,依赖关系用由类A指向类B的带箭头虚线表示。 4. 关联关系 关联体现的是两个类之间语义级别的一种强依赖关系,比如我和我的朋友,这种关系比依赖更强、不存在依赖关系的偶然性、关系也不是临时性的

9、,一般是长期性的,而且双方的关系一般是平等的。关联可以是单向、双向的。表现在代码层面,为被关联类B以类的属性形式出现在关联类A中,也可能是关联类A引用了一个类型为被关联类B的全局变量。在UML类图设计中,关联关系用由关联类A指向被关联类B的带箭头实线表示,在关联的两端可以标注关联双方的角色和多重性标记。 5. 聚合关系 聚合是关联关系的一种特例,它体现的是整体与部分的关系,即has-a的关系。此时整体与部分之间是可分离的,它们可以具有各自的生命周期,部分可以属于多个整体对象,也可以为多个整体对象共享。比如计算机与CPU、公司与员工的关系等,比如一个航母编队包括海空母舰、驱护舰艇、舰载飞机及核动

10、力攻击潜艇等。表现在代码层面,和关联关系是一致的,只能从语义级别来区分。在UML类图设计中,聚合关系以空心菱形加实线箭头表示。 6. 组合关系 组合也是关联关系的一种特例,它体现的是一种contains-a的关系,这种关系比聚合更强,也称为强聚合。它同样体现整体与部分间的关系,但此时整体与部分是不可分的,整体的生命周期结束也就意味着部分的生命周期结束,比如人和人的大脑。表现在代码层面,和关联关系是一致的,只能从语义级别来区分。在UML类图设计中,组合关系以实心菱形加实线箭头表示。 7. 总结 对于继承、实现这两种关系没多少疑问,它们体现的是一种类和类、或者类与接口间的纵向关系。其他的四种关系体

11、现的是类和类、或者类与接口间的引用、横向关系,是比较难区分的,有很多事物间的关系要想准确定位是很难的。前面也提到,这四种关系都是语义级别的,所以从代码层面并不能完全区分各种关系,但总的来说,后几种关系所表现的强弱程度依次为:组合聚合关联依赖。5.2 面向对象的基本原则什么是面向对象的基本原则?设计原则是基本的工具,应用这些规则可以使你的代码更加灵活、更容易维护,更容易扩展。 面向对象的基本原则包括:1. 面向接口编程而不是面向实现 Code to an interface rather than to an implementation. 2. 优先使用组合而非继承 Favor Composi

12、tion Over Inheritance. 3. SRP: The single responsibility principle 单一职责 系统中的每一个对象都应该只有一个单独的职责,而所有对象所关注的就是自身职责的完成。Every object in your system should have a single responsibility, and all the object s services should be focused on carrying out that single responsibility. 每一个职责都是一个设计的变因,需求变化的时候,需求变化反映为

13、类职责的变化。当你系统里面的对象都只有一个变化的原因的时候,你就已经很好的遵循了SRP原则。 如果一个类承担的职责过多,就等于把这些职责耦合在了一起。一个职责的变化就可能削弱或者抑制这个类其它职责的能力。这种设计会导致脆弱的设计。当变化发生的时候,设计会遭到意想不到的破坏。SRP 让这个系统更容易管理维护,因为不是所有的问题都搅在一起。 内聚Cohesion其实是SRP原则的另外一个名字,你写了高内聚的软件其实就是说你很好的应用了SRP原则。 4. DRY : Dont repeat yourself Principle 避免代码重复原则 通过抽取公共部分放置在一个地方避免代码重复。Avoid

14、 duplicate code by abstracting out things that are common and placing those thing in a single location. DRY很简单,但却是确保我们代码容易维护和复用的关键。你尽力避免重复代码实际上是在确保每一个需求和功能在你的系统中只实现一次,否则就存在浪费!系统用例不存在交集,所以我们的代码更不应该重复,从这个角度看DRY可就不只是在说代码了。 DRY 关注的是系统内的信息和行为都放在一个单一的,明显的位置。就像你可以猜到 正则 表达式在java中的位置一样,因为合理所以可以猜到。 DRY 原则:如何对

15、系统职能进行良好的分割!职责清晰的界限一定程度上保证了代码的单一性。 5. OCP : Open-Close Principle 开放闭合原则 类应该对修改关闭,对扩展打开;Classes should be open for extension, and closed for modification. OCP 关注的是灵活性,改动是通过增加代码进行的,而不是改动现有的代码; OCP的应用限定在可能会发生的变化上,通过创建抽象来隔离以后可能发生的同类变化 OCP原则传递出来这样一个思想:一旦你写出来了可以工作的代码,就要努力保证这段代码一直可以工作。这可以说是一个底线。稍微提高一点要求,一旦

16、我们的代码质量到了一个水平,我们要尽最大努力保证代码质量不回退。这样的要求使我们面对一个问题的时候不会使用凑合的方法来解决,或者说是放任自流的方式来解决一个问题;比如代码添加了无数对特定数据的处理,特化的代码越来越多,代码意图开始含混不清,开始退化。 OCP背后的机制:封装和抽象;封闭是建立在抽象基础上的,使用抽象获得显示的封闭;继承是OCP最简单的例子。除了子类化和方法重载我们还有一些更优雅的方法来实现比如组合; 怎样在不改变源代码(关闭修改)的情况下更改它的行为呢?答案就是抽象,OCP背后的机制就是抽象和多态,没有一个可以适应所有情况的贴切的模型!一定会有变化,不可能完全封闭。对程序中的每

17、一个部分都肆意的抽象不是一个好主意,正确的做法是开发人员仅仅对频繁变化的部分做出抽象。拒绝不成熟的抽象和抽象本身一样重要。OCP是OOD很多说法的核心,如果这个原则有效应用,我们就可以获更强的可维护性、可重用、灵活性、健壮性。LSP是OCP成为可能的主要原则之一 6. LSP: The Liskov substitution principle 里氏替代原则 子类必须能够替代基类。Subtypes must be substitutable for their base types. LSP关注的是怎样良好的使用继承,必须要清楚是使用一个Method还是要扩展它,但是绝对不是改变它。 LSP清

18、晰的指出,OOD的IS-A关系是就行为方式而言,行为方式是可以进行合理假设的,是客户程序所依赖的。 LSP让我们得出一个重要的结论:一个模型如果孤立的看,并不具有真正意义的有效性。模型的有效性只能通过它的客户程序来表现。必须根据设计的使用者做出的 合理假设来审视它。而假设是难以预测的,直到设计臭味出现的时候才处理它们。 对于LSP的违反也潜在的违反了OCP 。 7. DIP:依赖倒置原则 高层模块不应该依赖于底层模块。二者都应该依赖于抽象,抽象不应该依赖于细节,细节应该依赖于抽象。 什么是高层模块?高层模块包含了应用程序中重要的策略选择和业务模型。这些高层模块使其所在的应用程序区别于其它。 如

19、果高层模块依赖于底层模块,那么在不同的上下文中重用高层模块就会变得十分困难。然而,如果高层模块独立于底层模块,那么高层模块就可以非常容易的被重用。该原则就是框架设计的核心原则。这里的倒置不仅仅是依赖关系的倒置也是接口所有权的倒置。应用了DIP我们会发现往往是客户拥有抽象的接口,而服务者从这些抽象接口派生。这就是著名的Hollywood原则:Dont call us well call you.底层模块实现了在高层模块声明并被高层模块调用的接口。通过倒置我们创建了更灵活、更持久、更容易改变的结构。 DIP的简单的启发规则:依赖于抽象;这是一个简单的陈述,该规则建议不应该依赖于具体的类,也就是说程

20、序汇总所有的依赖都应该种植于抽象类或者接口。如果一个类很稳定,那么依赖于它不会造成伤害。然而我们自己的具体类大多是不稳定的,通过把他们隐藏在抽象接口后面可以隔离不稳定性。依赖倒置可以应用于任何存在一个类向另一个类发送消息的地方,依赖倒置原则是实现许多面向对象技术多宣称的好处的基本底层机制,是面向对象的标志所在。 8. ISP:接口隔离原则 不应该强迫客户程序依赖它们不需要的使用的方法。 接口不是高内聚的,一个接口可以分成N组方法,那么这个接口就需要使用ISP处理一下。 接口的划分是由使用它的客户程序决定的,客户程序是分离的接口也应该是分离的。 一个接口中包含太多行为时候,导致它们的客户程序之间

21、产生不正常的依赖关系,我们要做的就是分离接口,实现解耦。 应用了ISP之后,客户程序看到的是多个内聚的接口。 5.3 参考资料1. 推荐网站 /blog/493326 /blog/80261 /oobject/200804101.asp /design_pattern/ocp.html /design_pattern/srp.html /design_pattern/lsr.html /des

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论