Java面向对象程序设计的基本原则.docxVIP

Java面向对象程序设计的基本原则.docx

  1. 1、本文档共4页,可阅读全部内容。
  2. 2、有哪些信誉好的足球投注网站(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  5. 5、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  6. 6、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  7. 7、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  8. 8、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
在软件软件系统中,一个模块设计得好不好的最主要、最重要的标志,就是该模块在多大程度上将自己的内部数据和其他与实现有关的细节隐藏起来。一个设计得好的模块可以将它所有的实现细节隐藏起来,彻底地将提供给外界的API和自己的实现分隔开来。这样一来,模块与模块之间就可以仅仅通过彼此的API相互通信,而不理会模块内部的工作细节。         OO设计根本的指导原则是提高可维护性和可复用性。这些原则主要有:   1. 开闭原则   一个软件实体应该对扩展开放,对修改关闭。   在设计一个模块的时候,就当使这个模块可以在不被修改的前提下被扩展。换言之,就当可以在不必修改源代码的情况下改变这个模块的行为。      如何做到既不修改,又可以扩展?   解决问题的关键在于抽象化:在Java语言里,可以给出一个或多个抽象Java类或Java接口,规定出所有的具体类必须提供的方法特征作为系统设计的抽象层。这个抽象层预见了所有的可能扩展,因此,在任何扩展情况下都不会改变。这就使得系统的抽象层不需要修改,从而满足了—对修改关闭。   同时,由于从抽象层导出一个或多个新的具体类可以改变系统的行为,因此系统的设计对扩展是开放的。      开闭原则实际上是对“对可变性的封闭原则“:找到一个系统的可变因素,将之封装起来。这个原则意昧着两点:   1) 一个可变性不应当散落在代码的很多角落里,而应当被封装到一个对象里面。同一种可变性的不同表象意昧着同一个继承等级结构中的具体子类。   继承就当被看作是封装变化的方法,而不应当被认为是从一般的对象生成特殊对象的方法。   2) 一种可变性不应当与另一种可变性混合在一起。(所有类图的继承结构一般不会超过两层,不然就意昧着将两种不同的可变性混合在了一起。)      开闭原则是总的原则,其它几条是开闭原则的手段和工具。      2. 依赖倒转原则   依赖倒转原则讲的是:要依赖于抽象,不要信赖于实现。   开闭原则是目标,而达到这一目标的手段是依赖倒转原则。   抽象层次包含的是应用系统的商务逻辑和宏观的、对整个系统来说重要的战略性决定,是必然性的体现;而具体层次则含有一些次要的与实现有关的算法和逻辑,以及战术性的决定,带有相当大的偶然性选择。具体层次的代码是会经常有变动的,不能避免出现错误。   抽象层次含有一个应用系统最重要的宏观商务逻辑,是做战略判断和决定的地方,那么抽象层次就应当是较为稳定的,应当是复用的重点;也应当是维护的重点。   在很多情况下,一个Java程序需要引用一个对象。这个时候,如果这个对象有一个抽象类型的话,应当使用这个抽象类型作为变量的静态类型。这就是针对接口编程的含义。   一般而言,在创建一个对象时,Java语言要求使用new关键词以及这个类本身。而一旦这个对象已经被创建出来,那么就可以灵活地使用这个对象的抽象类型来引用它。比如:List employees = new Vector();因此,Java语言中创建一个对象的过程是违背“开闭原则”以及依赖倒转原则的(因为先生成了具体的类型,再使用抽象的引用),虽然在这个类被创建出来以后,可以通过多态性使得客户端依赖于其抽象类型。正是由于这个问题,设计模式给出了多个创建模式,特别是几个工厂模式,用于解决对象创建过程中的依赖倒转问题。   工厂模式将创建一个类的实例的过程封装起来,消费这个实例的客户端仅仅取得实例化的结果,以及这个实例的抽象类型。当然,任何方法都无法回避Java语言所要求的new关键字和直接调用具体类的构造子的做法(这违背了里氏代换原则)。简单工厂模式将这个违反“开闭原则”和依赖倒转原则的做法封装到了一个类里面,而工厂方法模式将这个违反原则的做法推迟到了具体工厂角色中。通过适当的封装,工厂模式可以净化大部分的结构,而将违反原则的做法孤立到易于控制的地方。      联合使用Java接口和Java抽象类:声明类型的工作由Java接口承担,但是同时给出的还有一个Java抽象类,为这个接口给出一个缺省实现。如果一个具体类直接实现这个Java接口的话,它就必须自行实现所有的接口;相反,如果它继承自抽象类的话,它就可以省去一些不必要的方法,因为它可以从抽象类中自动得到这些方法的缺省实现。这其实就是缺省适配模式。      依赖倒转的缺点:   1) 因为依赖倒转的缘故,对象的创建很可能要使用对象工厂,以避免对具体类的直接引用,此原则的使用还会导致大量的类。对不熟悉面向对象技术的工程师来说,维护这样的系统需要较好地面向对象的设计知识。   2) 依赖倒转原则假定所有的具体类都是会变化的,这也不总是正确的。有一些具体类可能相当稳定、不会发生变化,消费这个具体类实例的客户端完全可以依赖这个具体类型,而不必为此发

文档评论(0)

185****7617 + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档