软件专业毕业论文外文文献中英文翻译.doc

软件专业毕业论文外文文献中英文翻译 Object landscapes and lifetimesTechnically, OOP is just about abstract data typing, inheritance, and polymorphism, but other issues can be at least as important. The remainder of this section will cover these issues. One of the most important factors is the way objects are created and destroyed. Where is the data for an object and how is the lifetime of the object controlled? There are different philosophies at work here. C+ takes the approach that control of efficiency is the most important issue, so it gives the programmer a choice. For maximum run-time speed, the storage and lifetime can be determined while the program is being written, by placing the objects on the stack (these are sometimes called automatic or scoped variables) or in the static storage area. This places a priority on the speed of storage allocation and release, and control of these can be very valuable in some situations. However, you sacrifice flexibility because you must know the exact quantity, lifetime, and type of objects while youre writing the program. If you are trying to solve a more general problem such as computer-aided design, warehouse management, or air-traffic control, this is too restrictive. The second approach is to create objects dynamically in a pool of memory called the heap. In this approach, you dont know until run-time how many objects you need, what their lifetime is, or what their exact type is. Those are determined at the spur of the moment while the program is running. If you need a new object, you simply make it on the heap at the point that you need it. Because the storage is managed dynamically, at run-time, the amount of time required to allocate storage on the heap is significantly longer than the time to create storage on the stack. (Creating storage on the stack is often a single assembly instruction to move the stack pointer down, and another to move it back up.) The dynamic approach makes the generally logical assumption that objects tend to be complicated, so the extra overhead of finding storage and releasing that storage will not have an important impact on the creation of an object. In addition, the greater flexibility is essential to solve the general programming problem. Java uses the second approach, exclusively. Every time you want to create an object, you use the new keyword to build a dynamic instance of that object. Theres another issue, however, and thats the lifetime of an object. With languages that allow objects to be created on the stack, the compiler determines how long the object lasts and can automatically destroy it. However, if you create it on the heap the compiler has no knowledge of its lifetime. In a language like C+, you must determine programmatically when to destroy the object, which can lead to memory leaks if you dont do it correctly (and this is a common problem in C+ programs). Java provides a feature called a garbage collector that automatically discovers when an object is no longer in use and destroys it. A garbage collector is much more convenient because it reduces the number of issues that you must track and the code you must write. More important, the garbage collector provides a much higher level of insurance against the insidious problem of memory leaks (which has brought many a C+ project to its knees). The rest of this section looks at additional factors concerning object lifetimes and landscapes. 1. The singly rooted hierarchyOne of the issues in OOP that has become especially prominent since the introduction of C+ is whether all classes should ultimately be inherited from a single base class. In Java (as with virtually all other OOP languages) the answer is “yes” and the name of this ultimate base class is simply Object. It turns out that the benefits of the singly rooted hierarchy are many. All objects in a singly rooted hierarchy have an interface in common, so they are all ultimately the same type. The alternative (provided by C+) is that you dont know that everything is the same fundamental type. From a backward-compatibility standpoint this fits the model of C better and can be thought of as less restrictive, but when you want to do full-on object-oriented programming you must then build your own hierarchy to provide the same convenience thats built into other OOP languages. And in any new class library you acquire, some other incompatible interface will be used. It requires effort (and possibly multiple inheritance) to work the new interface into your design. Is the extra “flexibility” of C+ worth it? If you need itif you have a large investment in Cits quite valuable. If youre starting from scratch, other alternatives such as Java can often be more productive. All objects in a singly rooted hierarchy (such as Java provides) can be guaranteed to have certain functionality. You know you can perform certain basic operations on every object in your system. A singly rooted hierarchy, along with creating all objects on the heap, greatly simplifies argument passing (one of the more complex topics in C+). A singly rooted hierarchy makes it much easier to implement a garbage collector (which is conveniently built into Java). The necessary support can be installed in the base class, and the garbage collector can thus send the appropriate messages to every object in the system. Without a singly rooted hierarchy and a system to manipulate an object via a reference, it is difficult to implement a garbage collector. Since run-time type information is guaranteed to be in all objects, youll never end up with an object whose type you cannot determine. This is especially important with system level operations, such as exception handling, and to allow greater flexibility in programming. 2 .Collection libraries and support for easy collection useBecause a container is a tool that youll use frequently, it makes sense to have a library of containers that are built in a reusable fashion, so you can take one off the shelf Because a container is a tool that youll use frequently, it makes sense to have a library of containers that are built in a reusable fashion, so you can take one off the shelf and plug it into your program. Java provides such a library, which should satisfy most needs. Downcasting vs. templates/genericsTo make these containers reusable, they hold the one universal type in Java that was previously mentioned: Object. The singly rooted hierarchy means that everything is an Object, so a container that holds Objects can hold anything. This makes containers easy to reuse. To use such a container, you simply add object references to it, and later ask for them back. But, since the container holds only Objects, when you add your object reference into the container it is upcast to Object, thus losing its identity. When you fetch it back, you get an Object reference, and not a reference to the type that you put in. So how do you turn it back into something that has the useful interface of the object that you put into the container? Here, the cast is used again, but this time youre not casting up the inheritance hierarchy to a more general type, you cast down the hierarchy to a more specific type. This manner of casting is called downcasting. With upcasting, you know, for example, that a Circle is a type of Shape so its safe to upcast, but you dont know that an Object is necessarily a Circle or a Shape so its hardly safe to downcast unless you know thats what youre dealing with. Its not completely dangerous, however, because if you downcast to the wrong thing youll get a run-time error called an exception, which will be described shortly. When you fetch object references from a container, though, you must have some way to remember exactly what they are so you can perform a proper downcast. Downcasting and the run-time checks require extra time for the running program, and extra effort from the programmer. Wouldnt it make sense to somehow create the container so that it knows the types that it holds, eliminating the need for the downcast and a possible mistake? The solution is parameterized types, which are classes that the compiler can automatically customize to work with particular types. For example, with a parameterized container, the compiler could customize that container so that it would accept only Shapes and fetch only Shapes. Parameterized types are an important part of C+, partly because C+ has no singly rooted hierarchy. In C+, the keyword that implements parameterized types is “template.” Java currently has no parameterized types since it is possible for it to get byhowever awkwardlyusing the singly rooted hierarchy. However, a current proposal for parameterized types uses a syntax that is strikingly similar to C+ templates. 对象的创建和存在时间从技术角度说，OOP（面向对象程序设计）只是涉及抽象的数据类型、继承以及多形性，但另一些问题也可能显得非常重要。本节将就这些问题进行探讨。最重要的问题之一是对象的创建及破坏方式。对象需要的数据位于哪儿，如何控制对象的“存在时间”呢？针对这个问题，解决的方案是各异其趣的。C+认为程序的执行效率是最重要的一个问题，所以它允许程序员作出选择。为获得最快的运行速度，存储以及存在时间可在编写程序时决定，只需将对象放置在堆栈（有时也叫作自动或定域变量）或者静态存储区域即可。这样便为存储空间的分配和释放提供了一个优先级。某些情况下，这种优先级的控制是非常有价值的。然而，我们同时也牺牲了灵活性，因为在编写程序时，必须知道对象的准确的数量、存在时间、以及类型。如果要解决的是一个较常规的问题，如计算机辅助设计、仓储管理或者空中交通控制，这一方法就显得太局限了。第二个方法是在一个内存池中动态创建对象，该内存池亦叫“堆”或者“内存堆”。若采用这种方式，除非进入运行期，否则根本不知道到底需要多少个对象，也不知道它们的存在时间有多长，以及准确的类型是什么。这些参数都在程序正式运行时才决定的。若需一个新对象，只需在需要它的时候在内存堆里简单地创建它即可。由于存储空间的管理是运行期间动态进行的，所以在内存堆里分配存储空间的时间比在堆栈里创建的时间长得多（在堆栈里创建存储空间一般只需要一个简单的指令，将堆栈指针向下或向下移动即可）。由于动态创建方法使对象本来就倾向于复杂，所以查找存储空间以及释放它所需的额外开销不会为对象的创建造成明显的影响。除此以外，更大的灵活性对于常规编程问题的解决是至关重要的。C+允许我们决定是在写程序时创建对象，还是在运行期间创建，这种控制方法更加灵活。大家或许认为既然它如此灵活，那么无论如何都应在内存堆里创建对象，而不是在堆栈中创建。但还要考虑另外一个问题，亦即对象的“存在时间”或者“生存时间”（Lifetime）。若在堆栈或者静态存储空间里创建一个对象，编译器会判断对象的持续时间有多长，到时会自动“破坏”或者“清除”它。程序员可用两种方法来破坏一个对象：用程序化的方式决定何时破坏对象，或者利用由运行环境提供的一种“垃圾收集器”特性，自动寻找那些不再使用的对象，并将其清除。当然，垃圾收集器显得方便得多，但要求所有应用程序都必须容忍垃圾收集器的存在，并能默许随垃圾收集带来的额外开销。但这并不符合C+语言的设计宗旨，所以未能包括到C+里。但Java确实提供了一个垃圾收集器（Smalltalk也有这样的设计；尽管Delphi默认为没有垃圾收集器，但可选择安装；而C+亦可使用一些由其他公司开发的垃圾收集产品）。本节剩下的部分将讨论操纵对象时要考虑的另一些因素。1 单根结构在面向对象的程序设计中，由于C+的引入而显得尤为突出的一个问题是：所有类最终是否都应从单独一个基础类继承。在Java中（与其他几乎所有OOP语言一样），对这个问题的答案都是肯定的，而且这个终级基础类的名字很简单，就是一个“Object”。这种“单根结构”具有许多方面的优点。单根结构中的所有对象都有一个通用接口，所以它们最终都属于相同的类型。另一种方案（就象C+那样）是我们不能保证所有东西都属于相同的基本类型。从向后兼容的角度看，这一方案可与C模型更好地配合，而且可以认为它的限制更少一些。但假期我们想进行纯粹的面向对象编程，那么必须构建自己的结构，以期获得与内建到其他OOP语言里的同样的便利。需添加我们要用到的各种新类库，还要使用另一些不兼容的接口。理所当然地，这也需要付出额外的精力使新接口与自己的设计方案配合（可能还需要多重继承）。为得到C+额外的“灵活性”，付出这样的代价值得吗？当然，如果真的需要如果早已是C专家，如果对C有难舍的情结那么就真的很值得。但假如你是一名新手，首次接触这类设计，象Java那样的替换方案也许会更省事一些。单根结构中的所有对象（比如所有Java对象）都可以保证拥有一些特定的功能。在自己的系统中，我们知道对每个对象都能进行一些基本操作。一个单根结构，加上所有对象都在内存堆中创建，可以极大简化参数的传递（这在C+里是一个复杂的概念）。利用单根结构，我们可以更方便地实现一个垃圾收集器。与此有关的必要支持可安装于基础类中，而垃圾收集器可将适当的消息发给系统内的任何对象。如果没有这种单根结构，而且系统通过一个句柄来操纵对象，那么实现垃圾收集器的途径会有很大的不同，而且会面临许多障碍。由于运行期的类型信息肯定存在于所有对象中，所以永远不会遇到判断不出一个对象的类型的情况。这对系统级的操作来说显得特别重要，比如违例控制；而且也能在程序设计时获得更大的灵活性。2 集合库与方便使用集合由于集合是我们经常都要用到的一种工具，所以一个集合库是十分必要的，它应该可以方便地重复使用。这样一来，我们就可以方便地取用各种集合，将其插入自己的程序。Java提供了这样的一个库，尽管它在Java 1.0和1.1中都显得非常有限（Java 1.2的集合库则无疑是一个杰作）。下溯造型与模板通用性为了使这些集合能够重复使用，或者“再生”，Java提供了一种通用类型，以前曾把它叫作“Object”。单根结构意味着、所有东西归根结底都是一个对象”！所以容纳了Object的一个集合实际可以容纳任何东西。这使我们对它的重复使用变得非常简便。为使用这样的一个集合，只需添加指向它的对象句柄即可，以后可以通过句柄重新使用对象。但由于集合只能容纳Object，所以在我们向集合里添加对象句柄时，它会上溯造型成Object，这样便丢失了它的身份或者标识信息。再次使用它的时候，会得到一个Object句柄，而非指向我们早先置入的那个类型的句柄。所以怎样才能归还它的本来面貌，调用早先置入集合的那个对象的有用接口呢？在这里，我们再次用到了造型（Cast）。但这一次不是在分级结构中上溯造型成一种更“通用”的类型。而是下溯造型成一种更“特殊”的类型。这种造型方法叫作“下溯造型”（Downcasting）。举个例子来说，我们知道在上溯造型的时候，Circle（圆）属于Shape（几何形状）的一种类型，所以上溯造型是安全的。但我们不知道一个Object到底是Circle还是Shape，所以很难保证下溯造型的安全进行，除非确切地知道自己要操作的是什么。但这也不是绝对危险的，因为假如下溯造型成错误的东西，会得到我们称为“违例”（Exception）的一种运行期错误。我们稍后即会对此进行解释。但在从一个集合提取对象句柄时，必须用某种方式准确地记住它们是什么，以保证下溯造型的正确进行。下溯造型和运行期检查都要求花额外的时间来运行程序，而且程序员必须付出额外的精力。既然如此，我们能不能创建一个“智能”集合，令其知道自己容纳的类型呢？这样做可消除下溯造型的必要以及潜在的错误。答案是肯定的，我们可以采用“参数化类型”，它们是编译器能自动定制的类，可与特定的类型配合。例如，通过使用一个参数化集合，编译器可对那个集合进行定制，使其只接受Shape，而且只提取Shape。参数化类型是C+一个重要的组成部分，这部分是C+没有单根结构的缘故。在C+中，用于实现参数化类型的关键字是template（模板）。Java目前尚未提供参数化类型，因为由于使用的是单根结构，所以使用它显得有些笨拙。但这并不能保证以后的版本不会实现，因为“generic”这个词已被Java“保留到将来实现”（在Ada语言中，“generic”被用来实现它的模板）。Java采取的这种关键字保留机制其实经常让人摸不着头脑，很难断定以后会发生什么事情。1. 基于C8051F单片机直流电动机反馈控制系统的设计与研究2. 基于单片机的嵌入式Web服务器的研究 3. MOTOROLA单片机MC68HC（8）05PV8/A内嵌EEPROM的工艺和制程方法及对良率的影响研究 4. 基于模糊控制的电阻钎焊单片机温度控制系统的研制 5. 基于MCS-51系列单片机的通用控制模块的研究 6. 基于单片机实现的供暖系统最佳启停自校正（STR）调节器7. 单片机控制的二级倒立摆系统的研究8. 基于增强型51系列单片机的TCP/IP协议栈的实现 9. 基于单片机的蓄电池自动监测系统 10. 基于32位嵌入式单片机系统的图像采集与处理技术的研究11. 基于单片机的作物营养诊断专家系统的研究 12. 基于单片机的交流伺服电机运动控制系统研究与开发 13. 基于单片机的泵管内壁硬度测试仪的研制 14. 基于单片机的自动找平控制系统研究 15. 基于C8051F040单片机的嵌入式系统开发 16. 基于单片机的液压动力系统状态监测仪开发 17. 模糊Smith智能控制方法的研究及其单片机实现 18. 一种基于单片机的轴快流CO,2激光器的手持控制面板的研制 19. 基于双单片机冲床数控系统的研究 20. 基于CYGNAL单片机的在线间歇式浊度仪的研制 21. 基于单片机的喷油泵试验台控制器的研制 22. 基于单片机的软起动器的研究和设计 23. 基于单片机控制的高速快走丝电火花线切割机床短循环走丝方式研究 24. 基于单片机的机电产品控制系统开发 25. 基于PIC单片机的智能手机充电器 26. 基于单片机的实时内核设计及其应用研究 27. 基于单片机的远程抄表系统的设计与研究 28. 基于单片机的烟气二氧化硫浓度检测仪的研制 29. 基于微型光谱仪的单片机系统 30. 单片机系统软件构件开发的技术研究 31. 基于单片机的液体点滴速度自动检测仪的研制32. 基于单片机系统的多功能温度测量仪的研制 33. 基于PIC单片机的电能采集终端的设计和应用 34. 基于单片机的光纤光栅解调仪的研制 35. 气压式线性摩擦焊机单片机控制系统的研制 36. 基于单片机的数字磁通门传感器 37. 基于单片机的旋转变压器-数字转换器的研究 38. 基于单片机的光纤Bragg光栅解调系统的研究 39. 单片机控制的便携式多功能乳腺治疗仪的研制 40. 基于C8051F020单片机的多生理信号检测仪 41. 基于单片机的电机运动控制系统设计 42. Pico专用单片机核的可测性设计研究 43. 基于MCS-51单片机的热量计 44. 基于双单片机的智能遥测微型气象站 45. MCS-51单片机构建机器人的实践研究 46. 基于单片机的轮轨力检测 47. 基于单片机的GPS定位仪的研究与实现 48. 基于单片机的电液伺服控制系统 49. 用于单片机系统的MMC卡文件系统研制 50. 基于单片机的时控和计数系统性能优化的研究 51. 基于单片机和CPLD的粗光栅位移测量系统研究 52. 单片机控制的后备式方波UPS 53. 提升高职学生单片机应用能力的探究 54. 基于单片机控制的自动低频减载装置研究 55. 基于单片机控制的水下焊接电源的研究 56. 基于单片机的多通道数据采集系统 57. 基于uPSD3234单片机的氚表面污染测量仪的研制 58. 基于单片机的红外测油仪的研究 59. 96系列单片机仿真器研究与设计 60. 基于单片机的单晶金刚石刀具刃磨设备的数控改造 61. 基于单片机的温度智能控制系统的设计与实现 62. 基于MSP430单片机的电梯门机控制器的研制 63. 基于单片机的气体测漏仪的研究 64. 基于三菱M16C/6N系列单片机的CAN/USB协议转换器 65. 基于单片机和DSP的变压器油色谱在线监测技术研究 66. 基于单片机的膛壁温度报警系统设计 67. 基于AVR单片机的低压无功补偿控制器的设计 68. 基于单片机船舶电力推进电机监测系统 69. 基于单片机网络的振动信号的采集系统 70. 基于单片机的大容量数据存储技术的应用研究 71. 基于单片机的叠图机研究与教学方法实践 72. 基于单片机嵌入式Web服务器技术的研究及实现 73. 基于AT89S52单片机的通用数据采集系统 74. 基于单片机的多道脉冲幅度分析仪研究 75. 机器人旋转电弧传感角焊缝跟踪单片机控制系统 76. 基于单片机的控制系统在PLC虚拟教学实验中的应用研究77. 基于单片机系统的网络通信研究与应用 78. 基于PIC16F877单片机的莫尔斯码自动译码系统设计与研究79. 基于单片机的模糊控制器在工业电阻炉上的应用研究 80. 基于双单片机冲床数控系统的研究与开发 81. 基于Cygnal单片机的C/OS-的研究82. 基于单片机的一体化智能差示扫描量热仪系统研究 83. 基于TCP/IP协议的单片机与Internet互联的研究与实现 84. 变频调速液压电梯单片机控制器的研究 85. 基于单片机-免疫计数器自动换样功能的研究与实现 86. 基于单片机的倒立摆控制系统设计与实现 87. 单片机嵌入式以太网防盗报警系统 88. 基于51单片机的嵌入式Internet系统的设计与实现 89. 单片机监测系统在挤压机上的应用 90. MSP430单片机在智能水表系统上的研究与应用 91. 基于单片机的嵌入式系统中TCP/IP协议栈的实现与应用92. 单片机在高楼恒压供水系统中的应用 93. 基于ATmega16单片机的流量控制器的开发 94. 基于MSP430单片机的远程抄表系统及智能网络水表的设计95. 基于MSP430单片机具有数据存储与回放功能的嵌入式电子血压计的设计 96. 基于单片机的氨分解率检测系统的研究与开发 97. 锅炉的单片机控制系统 98. 基于单片机控制的电磁振动式播种控制系统的设计 99. 基于单片机技术的WDR-01型聚氨酯导热系数测试仪的研制 100. 一种RISC结构8位单片机的设计与实现 101. 基于单片机的公寓用电智能管理系统设计 102. 基于单片机的温度测控系统在温室大棚中的设计与实现103. 基于MSP430单片机的数字化超声电源的研制 104. 基于ADC841单片机的防爆软起动综合控制器的研究105. 基于单片机控制的井下低爆综合保护系统的设计