Java程序怎么挑选出想要挑选的年份

在一个面向对象的系统中系统嘚各种功能是由许许多多的不同对象协作完成的。在这种情况下各个对象内部是如何实现自己的对系统设计人员来讲就不那么重要了;洏各个对象之间的协作关系则成为系统设计的关键。小到不同类之间的通信大到各模块之间的交互,在系统设计之初都是要着重考虑的这也是系统设计的主要工作内容。面向接口编程我想就是指按照这种思想来编程吧!实际上在日常工作中,你已经按照接口编程了呮不过如果你没有这方面的意识,那么你只是在被动的实现这一思想;表现在频繁的抱怨别人改的代码影响了你(接口没有设计到)表現在某个模块的改动引起其他模块的大规模调整(模块接口没有很好的设计)等等。

  Booch先生那天谈到Interaction Designer它就是指做这类设计的人,只不過层次更高一些我想目前我们的软件设计队伍中,这类人是最缺乏的人才之一


非接口编程?是不是就是面向过程的编程思想

  1.关於接口的理解。


  接口从更深层次的理解应是定义(规范,约束)与实现(名实分离的原则)的分离
  我们在一般实现一个系统嘚时候,通常是将定义与实现合为一体不加分离的,我认为最为理解的系统设计规范应是所有的定义与实现分离尽管这可能对系统中嘚某些情况有点繁烦。
  接口的本身反映了系统设计人员对系统的抽象理解
  接口应有两类:第一类是对一个体的抽象,它可对应為一个抽象体(abstract class);
  第二类是对一个体某一方面的抽象即形成一个抽象面(interface);
  一个体有可能有多个抽象面。
  抽象体与抽象面昰有区别的

  2.设计接口的另一个不可忽视的因素是接口所处的环境(context,environment),系统论的观点:环境是系统要素所处的空间与外部影响因素的总囷任何接口都是在一定的环境中产生的。因此环境的定义及环境的变化对接口的影响是不容忽视的脱离原先的环境,所有的接口将失詓原有的意义

  3.按照组件的开发模型(3C),它们三者相辅相成各司一面,浑然一体缺一不可。

  面向对象是指我们考虑问题時,以对象为单位考虑它的属性及方法


  面向过程是指,我们考虑问题时以一个具体的流程(事务过程)为单位,考虑它的实现
  接口设计与非接口设计是针对复用技术而言的与面向对象(过程)不是一个问题

  在具体实现中,是可以把UML的interface实现为语言的interface分布式对象环境的interface或其它什么interface,但就理解UML的interface而言指的是系统每部分的实现和实现之间,通过interface所确定的协议来共同工作

  所以我认为,面姠interface编程原意是指面向抽象协议编程,实现者在实现时要严格按协议来办也就是BillJoy同志说的,一边翻rfc一边写代码的意思。面向对象编程昰指面向抽象和具象抽象和具象是矛盾的统一体,不可能只有抽象没有具象一般懂得抽象的人都明白这个道理。 但有的人只知具象却鈈知抽象为何物

  所以只有interface没有实现,或只有实现而没有interface者是没有用的反OO的。

  所以还是老老实实面向对象编程面向协议编程,或者什么都不面向老老实实编程。

  但是我很讨厌讨论这样的术语不如我们谈谈什么叫面向领导的编程?面向用户的编程领导囷用户有时都很BT,我们就面向BT编程

选择Java接口还是抽象类

很多人有过这样的疑问:为什么有的地方必须使用接口而不是抽象类,而在另一些地方又必须使用抽象类而不是接口呢?或者说在考虑Java类的一般化问题时,很多人会在接口和抽象类之间犹豫不决甚至随便选择一種。

  实际上接口和抽象类的选择不是随心所欲的要理解接口和抽象类的选择原则,有两个概念很重要:对象的行为和对象的实现洳果一个实体可以有多种实现方式,则在设计实体行为的描述方式时应当达到这样一个目标:在使用实体的时候,无需详细了解实体行為的实现方式也就是说,要把对象的行为和对象的实现分离开来既然Java的接口和抽象类都可以定义不提供具体实现的方法,在分离对象嘚行为和对象的实现时到底应该使用接口还是使用抽象类呢?

通过抽象类建立行为模型

  在接口和抽象类的选择上必须遵守这样一個原则:行为模型应该总是通过接口而不是抽象类定义。为了说明其原因下面试着通过抽象类建立行为模型,看看会出现什么问题

  假设要为销售部门设计一个软件,这个软件包含一个“发动机”(Motor)实体显然无法在发动机对象中详细地描述发动机的方方面面,只能描述某些对当前软件来说重要的特征至于发动机的哪些特征是重要的,则要与用户(销售部门)交流才能确定

  销售部门的人要求每一个发动机都有一个称为马力的参数。对于他们来说这是惟一值得关心的参数。基于这一判断可以把发动机的行为定义为以下行為。

  行为1:查询发动机的马力发动机将返回一个表示马力的整数。

  虽然现在还不清楚发动机如何取得马力这个参数但可以肯萣发动机一定支持这个行为,而且这是所有发动机惟一值得关注的行为特征这个行为特征既可以用接口定义,也可以用抽象类定义为叻说明用抽象类定义可能出现的问题,下面用抽象类建立发动机的行为模型并用Java方法描述行为1,代码如下:


  在Motor抽象类的基础上构造絀多种具体实现例如A型发动机、B型发动机等,再加上系统的其它部分最后得到1.0版的软件并交付使用。一段时间过去了现在要设计2.0版嘚软件。在评估2.0版软件需求的过程中发现一小部分发动机是电池驱动的,而电池需要一定的充电时间销售部门的人希望能够通过计算機查阅充电时间。根据这一要求定义一个新的行为如图1所示。

  行为2:查询电驱动发动机的充电时间发动机将返回一个表示充电时間的整数。

  用Java方法来描述这个行为代码如下:


  在销售部门的软件中,电驱动发动机也以类的形式实现但这些类从BatteryPoweredMotor而不是Motor派生。这些改动加入到2.0版软件之后销售部门很满意。随着业务的不断发展不久之后光驱动的发动机出现了。销售部门要求光驱动发动机需偠一定光能才能运转光能以流明(Lumen)度量。这个信息对客户很重要因为下雨或多云的天气里,某些光驱动发动机可能无法运转销售蔀门要求为软件增加对光驱动发动机的支持,所以要定义一个新的行为

  行为3:查询光驱动发动机能够正常运转所需要的最小流明数,发动机返回一个整数

  再定义一个抽象类并把行为3转换成Java方法,代码如下:


  如图1所示SolarPoweredMotor和BatteryPoweredMotor都从Motor抽象类派生。在整个软件中90%鉯上的代码以相同的方式对待所有的发动机。偶尔需要检查一下发动机是光驱动还是电驱动使用instanceof实现,代码如下:


  现在销售部门又囿了一种新的发动机它是一种既有电驱动又有光驱动的双重驱动发动机。光驱动和电驱动的行为本身没有变化但新的发动机同时支持兩种行为。在考虑如何定义新型的光电驱动发动机时接口和抽象类的差别开始显示出来了。新的目标是在增加新型发动机的前提下尽量尐改动代码因为与光驱动发动机、电驱动发动机有关的代码已经过全面的测试,不存在已知的Bug为了增加光电驱动发动机,要定义一个噺的SolarBatteryPowered抽象类如果让SolarBatteryPowered从Motor抽象类派生,SolarBatteryPowered将不支持针对光驱动发动机和电驱动发动机的instanceof操作也就是说,如果查询一个光电驱动的发动机是光驅动的还是电驱动的,得到的答案是:都不是

  如果让SolarBatteryPowered从SolarPoweredMotor(或BatteryPoweredMotor)抽象类派生,类似的问题也会出现SolarBatteryPowered将不支持针对BatteryPoweredMotor(或SolarPoweredMotor)的instanceof操作。從行为上看光电驱动的发动机必须同时从两个抽象类派生,但Java语言不允许多重继承之所以会出现这个问题,根本的原因在于使用抽象類不仅意味着定义特定的行为而且意味着定义实现的模式。也就是说应该定义一个发动机如何获得行为的模型,而不仅仅是声明发动機具有某一个行为

  如果用接口来建立行为模型,就可以避免隐含地规定实现模式例如,前面的几个行为改用接口定义如下




  現在光电驱动的发动机可以描述为:


  DualPoweredMotor只继承行为定义,而不是行为的实现模式如图2所示。

  在使用接口的同时仍旧可以使用抽象類不过这时抽象类的作用是实现行为,而不是定义行为只要实现行为的类遵从接口定义,即使它改变了父抽象类也不用改变其它代碼与之交互的方式。特别是对于公用的实现代码抽象类有它的优点。抽象类能够保证实现的层次关系避免代码重复。然而即使在使鼡抽象类的场合,也不要忽视通过接口定义行为模型的原则从实践的角度来看,如果依赖于抽象类来定义行为往往导致过于复杂的继承关系,而通过接口定义行为能够更有效地分离行为与实现为代码的维护和修改带来方便。


在Java中看到接口第一个想到的可能就是C++中的哆重继承和Java中的另外一个关键字abstract。从另外一个角度实现多重继承是接口的功能之一接口的存在可以使Java中的对象可以向上转型为多个基类型,并且和抽象类一样可以防止他人创建该类的对象因为接口不允许创建对象。

interface关键字用来声明一个接口它可以产生一个完全抽象的類,并且不提供任何具体实现interface的特性整理如下:

interface在某些地方和abstract有相似的地方,但是采用哪种方式来声明类主要参照以下两点:

2.        如果知道某个类应该是基类那么第一个选择的应该是让它成为一个接口,只有在必须要有方法定义和成员变量的时候才应该选择抽象类。因为抽象类中允许存在一个或多个被具体实现的方法只要方法没有被全部实现该类就仍是抽象类。

以上就是接口的基本特性和应用的领域泹是接口绝不仅仅如此,在Java语法结构中接口可以被嵌套,既可以被某个类嵌套也可以被接口嵌套。这在实际开发中可能应用的不多泹也是它的特性之一。需要注意的是在实现某个接口时,并不需要实现嵌套在其内部的任何接口而且,private接口不能在定义它的类之外被實现

java中主要的排序方法分为两大类:內部排序和外部排序内部排序顾名思义就是将要排序的无序数列放到内存中去进行操作,而有一些无序数列大的惊人内存不能放下,所以就放到外存中去进行排序这就是外部排序

关于排序的分类,我在网上看到了一个图片能很清楚的表现他们的分类:

 

为了简化实现就用int举个例子:

(1)冒泡排序属于交换排序,根据元素比较结果交换元素最终达到排序的目的。

(1)属于选择排序选择排序指的是第i趟,在n-i+1个元素中選择最小值加入到新序列中。

转载请注明出处谢谢合作

我要回帖

 

随机推荐