Introduction to Object-Oriented Programming（4.1）
Object-oriented programming, or OOP for short, is the dominant programming paradigm these days, having replaced the “structured,” procedural programming techniques that were developed in the 1970s. Since Java is object-oriented, you have to be familiar with OOP to become productive with Java.
An object-oriented program is made of objects. Each object has a specific functionality, exposed to its users, and a hidden implementation. Many objects in your programs will be taken “off-the-shelf” from a library; others will be custom-designed. Whether you build an object or buy it might depend on your budget or on time. But, basically, as long as an object satisfies your specifications, you donrsquo;t care how the functionality is implemented.
Traditional structured programming consists of designing a set of procedures (or algorithms ) to solve a problem. Once the procedures are determined, the traditional next step was to find appropriate ways to store the data. This is why the designer of the Pascal language, Niklaus Wirth, called his famous book on programming Algorithms Data Structures = Programs (Prentice Hall, 1975). Notice that in Wirthrsquo;s title, algorithms come first, and data structures come second. This mimics the way programmers worked at that time. First, they decided on the procedures for manipulating the data; then, they decided what structure to impose on the data to make the manipulations easier. OOP reverses the order: puts the data first, then looks at the algorithms to operate on the data.
For small problems, the breakdown into procedures works very well. But objects are more appropriate for larger problems. Consider a simple web browser. It might require 2,000 procedures for its implementation, all of which manipulate a set of global data. In the object-oriented style, there might be 100 classes with an average of 20 methods per class (see Figure 4.1). This structure is much easier for a programmer to grasp. It is also much easier to find bugs in. Suppose the data of a particular object is in an incorrect state. It is far easier to search for the culprit among the 20 methods that had access to that data item than among 2,000 procedures
Introducing Swing(7.1)
When Java 1.0 was introduced, it contained a class library, which Sun called the Abstract Window Toolkit (AWT), for basic GUI programming. The basic AWT library deals with user interface elements by delegating their creation and behavior to the native GUI toolkit on each target platform (Windows, Solaris, Macintosh, and so on). For example, if you used the original AWT to put a text box on a Java window, an underlying “peer” text box actually handled the text input. The resulting program could then, in theory, run on any of these platforms, with the “look-and-feel” of the target platform—hence Sunrsquo;s trademarked slogan: “Write Once, Run Anywhere.” The peer-based approach worked well for simple applications, but it soon became apparent that it was fiendishly difficult to write a high-quality portable graphics library depending on native user interface elements. User interface elements such as menus, scrollbars, and text fields can have subtle differences in behavior on different platforms. It was hard, therefore, to give users a consistent and predictable experience with this approach. Moreover, some graphical environments (such as X11/Motif) do not have as rich a collection of user interface components as does Windows or the Macintosh. This, in turn, further limits a portable library
based on a “lowest common denominator” approach. As a result, GUI applications built with the AWT simply did not look as nice as native Windows or Macintosh applications, nor did they have the kind of functionality that users of those platforms had come to expect. More depressingly, there were different bugs in the AWT user interface library on the different platforms. Developers complained that they had to test their applications on each platform—a practice derisively called “write once, debug everywhere.” In 1996, Netscape created a GUI library they called the IFC (Internet Foundation Classes) that used an entirely different approach. User interface elements, such as buttons, menus, and so on, were painted onto blank windows. The only functionality required from the underlying windowing system was a way to put up windows and to paint on the window. Thus, Netscapersquo;s IFC widgets looked and behaved the same no matter which platform the program ran on. Sun worked with Netscape to perfect this approach, creating a user interface library with the code name “Swing.” Swing was available as an extension to Java 1.1 and became a part of the standard library in Java SE 1.2. Since, as Duke Ellington said, “It Donrsquo;t Mean a Thing If It Ainrsquo;t Got That Swing,” Swing is now the official name for the non-peer-based GUI toolkit. Swing is part of the Java Foundation Classes (JFC). The full JFC is vast and contains far more than the Swing GUI toolkit; besides the Swing components, it also has an accessibility API, a 2D API, and a drag-and-drop API.
Creating a Frame(7.2)
A top-level window (that is, a window that is not contained inside another window) is called a frame in Java. The AWT library has a class, called Frame, for this top level. The Swing version of this class is called JFrame and extends the Frame class. The JFrame is one of the few Swing components that is not painted on a canvas. Thus, the decorations (buttons, title bar, icons, and so on) are drawn by the userrsquo;s windowing system, not by Swing.
Positioning a Frame (7.3)
The JFrame class itself has only a few methods for changing how frames look. Of course, through the magic of inheritance, most of the methods for working with the size and position of a frame come from the various superclasses of JFrame. Here are some
全文共19524字，剩余内容已隐藏，支付完成后下载完整资料
面向对象程序设计概述
面向对象程序设计 (简称 OOP) 是目前主流的程序设计范型，他已经取代了二十世纪七十年代开发的 '结构化' 过程化程序设计开发技术。由于 Java 是完全面向对象的, 因此您必须熟悉 OOP 以使用 Java 生产。
面向对象的程序是由对象组成的。每个对象都有一个特定的功能,暴露给它的用户和一个隐藏的实现。您程序中的许多对象将从库中 '现成' 地被取走;其他将被定制设计。无论您是建立一个对象还是购买它, 都可能取决于您的预算或时间。但基本上,只要对象满足您的规范, 您不关心如何实现功能。
传统的结构化编程包括设计一组过程 (或算法)来解决问题。一旦确定了这些过程, 传统的下一步就是找到存储数据的适当方法。这就是为什么Pascal语言的设计者, Niklaus Wirth将其著作命名为《算法 数据结构 = 程序》 (Algorithms Data Structures = Programs，Prentice Hall, 1975)的原因。请注意, 在 Wirth 命名的书名中, 算法首先出现, 而数据结构则是第二个。这就明确表达了程序员当时的工作方式。首先, 他们决定了操作数据的程序;然后, 他们决定对数据施加何种结构来简化操作。而OOP却调换了这个顺序，将数据放在第一位, 然后看算法对数据进行操作。
对于一些规模较小问题, 程序的分解很有效。但是对象更适合于更大的问题。请考虑一个简单的 web 浏览器。它可能需要2000程序来实现它, 所有这些过程都操纵一组全局数据。在面向对象的样式中, 可能有100个类, 每个类平均有20个方法 (请参见图 1)。这个结构对程序员来说更容易掌握。在中查找 bug 也更容易。假设数据的特定对象处于不正确的状态。在20种方法中, 可以比在2000个程序中搜索到该数据项的罪魁祸首要容易得多。
图1 面向过程与面向对象的程序设计对比
Swing概述
当 Java 1.0 刚被引入时, 它包含一个用于基本GUI程序设计的类库, Sun 称其为抽象窗口工具包 (AWT), 用于基本 GUI 编程。基本 AWT 库通过将其创建和行为委派给每个目标平台 (Windows、Solaris、Macintosh 等) 上的本机 GUI 工具包来处理用户界面元素。例如, 如果使用原始 AWT 将文本框放在 Java 窗口上, 就会有一个低层的 '对等体' 文本框，用来实际处理文本输入。由此产生的程序, 理论上, 可以运行在任何这些平台上, 与 '外观和感觉' 的目标平台-因此 Sun 的商标口号: '一次编写，随处使用“。
基于对等体的方法能很好地适用于简单的应用程序,。但是，要想编写依赖于本地用户界面元素的高质量、可移植的图形库就会暴露出一些缺陷。例如，用户界面元素 (如菜单、滚动条和文本字段) 在不同平台上的行为可能存在细微差异。因此, 很难为用户提供这种方法的一致和可预测的体验。此外, 某些图形环境 (如 X11/Motif) 没有丰富的集合用户界面组件的 Windows 或 Macintosh。这反过来又进一步限制了便携式库
基于 '最低共同点' 方法。因此, 使用 AWT 构建的 GUI 应用程序看起来并不像本机 Windows 或 Macintosh 应用程序那么好, 也没有这些平台的用户所期望的那种功能。更令人沮丧的是, 不同平台上的 AWT 用户界面库中存在不同的 bug。开发者抱怨他们必须在每个平台上测试他们的应用程序-一个练习嘲弄称为 '一次写, 调试无处不在'。在 1996年, Netscape创建了一个 GUI 库, 他们称之为IFC (Internet Foundation Class), 它使用了完全不同的方法。用户界面元素 (如按钮、菜单等) 被绘制到空白窗口中。基础窗口系统所需的唯一功能是在窗口上放置窗口和画图的方法。因此, Netscape的 IFC 小部件看起来和表现都是一样的, 不管程序运行在哪个平台上。Sun 与Netscape合作, 以完善这种方法, 创建一个用户界面库的代码名为 'Swing'。Swing 可作为 java 1.1 的扩展, 并成为 java SE 1.2 中标准库的一部分。因为, 正如Duke Ellington说, '这并不意味着一件事, 如果它不是得到了挥杆, 'swing 现在是非对等的 GUI 工具包的正式名称。Swing 是 Java 基础类 (JFC) 的一部分。完整的 JFC 是巨大的, 包含远远超过摆动 GUI 工具箱;除了 Swing 组件外, 它还具有可访问性 api、2D api 和可拖放 api。
创建框架
顶层窗口 (即不包含在另一个窗口中的窗口) 称为 Java 中的框架。AWT 库有一个称为Frame的类, 用于描述此顶层窗口。此类的 Swing 版本称为JFrame并扩展于Frame类。JFrame是没有在画布上绘制的几个 Swing 组件之一。因此, 他的修饰部件 (按钮、标题栏、图标等) 是由用户的窗口系统绘制的, 而不是通过Swing绘制。
框架定位
JFrame类本身只有几个方法来更改框架的外观。当然, 通过继承的魔力, 大多数处理框架大小和位置的方法来自于各种超类的jframe.下面是一些最重要的方法:
·setLocation和setBounds设置框架位置的方法
·setIconImage方法, 它告诉窗口系统哪个图标显示在标题栏, 任务切换窗口, 等等
·setTitle更改标题栏中文本的方法
·setResizable方法, 它需要一个布尔确定框架是否将resizeable由用户
图2给出JFrame类的继承层次。
图2 AWT 和 Swing 中框架和组件类的继承层次结构
提示:本节的 API 注释给出了我们认为最重要的方法, 给框架提供了正确的外观和感觉。中定义了其中的一些方法。jframe类.其他来自各种超类的jframe.在某种程度上, 您可能需要搜索 API 文档, 看看是否有一些特殊用途的方法。不幸的是, 对于继承的方法来说, 这有点乏味。例如,toFront方法适用于类型的对象jframe, 但因为它只是从窗口类继承,jframe文档无法解释它。如果您认为应该有一种方法来执行某项操作, 并且它在您所使用的类的文档中没有提到, 请尝试查看 API 文档中的超类。每个 API 页的顶部都有指向超类, 并且继承的方法列在下面的新的和重写的方法的方法摘要。
事件处理基础
任何支持 gui 的操作环境都要经常监视诸如击键或鼠标单击之类的事件。操作环境将这些事件报告给正在运行的程序。每个程序然后决定什么, 如果有的话, 做响应这些事件。在像 Visual Basic 这样的语言中, 事件和代码之间的通信是显而易见的。一个为每个特定事件编写代码, 并将代码放在通常称为事件程序.例如, 一个名为 'HelpButton'将有一个HelpButton_Click与之关联的事件过程。只要单击该按钮, 此过程中的代码就会执行。每个可视化基本 GUI 组件都响应一组固定的事件, 并且无法更改它响应的事件。另一方面, 如果您使用像原始C 这样的语言进行事件驱动编程, 则需要编写不断检查事件队列的代码, 以了解操作环境所报告的内容;这通常是通过在循环中用大量的开关语句将代码装箱来完成的。这项技术显然相当丑陋, 在任何情况下, 代码都更难。它的优点是, 您可以响应的事件不像语言那样受限制, 如 Visual Basic 一样, 可从程序员那里隐藏事件队列。Java 编程环境在视觉基础和原始 C 之间在功率和由此产生的复杂性之间采取某种方法。在 AWT 知道的事件的范围内, 您可以完全控制事件从事件源 (如按钮或滚动条) 传输到事件的方式。听众.您可以将任何对象指定为事件侦听器-在实践中, 选择一个可以方便地对事件执行所需响应的对象。此事件委派模型为您提供了比可视化更大的灵活性。
基本, 侦听器是预定的。事件源具有允许您注册事件侦听器的方法。当源发生事件时, 源会向为该事件注册的所有侦听器对象发送该事件的通知。正如 Java 中的一个面向对象的语言所期望的那样, 事件的信息被封装在事件中。对象.在 Java 中, 所有事件对象最终从类派生util.EventObject.当然, 每个事件类型都有子类, 例如ActionEvent和WindowEvent.不同的事件源可以生成不同类型的事件。例如, 按钮可以发送ActionEvent对象, 而窗口可以发送WindowEvent对象.
总而言之, 下面概述了 AWT 中事件处理的工作原理:
bull;监听器对象是一个类的实例, 它实现了一个称为监听器的特殊接口 (listener interface)的类的实例.
bull;事件源是一个可以注册监听器对象并将其发送到事件对象的对象。
bull;事件源在事件发生时向所有注册监听器发送事件对象。
bull;监听器对象将使用事件对象中的信息来确定它们对事件的反应。
AWT 事件继承 层次
在让您了解事件处理的工作原理之后, 我们将使用 AWT 事件处理体系结构的概述来完成本章。
正如我们前面简要提到的, Java 中的事件处理是面向对象的, 所有事件都从EventObject类的java.util包中扩展过来的(公共超类不称为事件, 因为这是旧事件模型中的 事件类的名称。虽然旧模型现在已过时, 但它的类仍然是 Java 库的一部分)。
EventObject类具有子类AWTEvent, 它是所有 AWT 事件类的父级。图3显示 AWT 事件的继承关系图。
图3.AWT 事件类的继承关系图
有些 Swing 组件将生成其他事件类型的事件对象；他们都直接扩展于EventObject,而不是AWTEvent 。
事件对象封装有关事件源与其监听器通信的事件的信息。必要时, 您可以分析传递给侦听器对象的事件对象, 就像我们在按钮示例中使用getSource和getActionCommand方法.
某些 AWT 事件类对于 Java 程序员来说是没有实际用途的。例如, AWT 插入PaintEvent对象放入事件队列中, 但这些对象不会传递给监听器。Java 程序员并不监听绘图事件;相反, 它们会覆盖paintComponent方法来控制重绘。AWT还生成了许多只有系统程序员才需要的事件, 为象形字语言提供输入系统, 自动测试机器人等等。我们不讨论这些特殊的事件类型.
设计模式(9.1)
在解决问题时, 通常不会从第一个原则中找出解决方案。相反, 你可能会被你的过往经验, 或者你可以向其他专家请教他们的工作。设计模式是一种以结构化的方式呈现此专业技能的方法。近年来, 软件工程师已经开始组装这种模式的目录。这一领域的先驱们受到建筑师克里斯托弗bull;亚历山大的建筑设计模式的启发。在他的书中,《永恒的建筑方式 》(牛津大学出版社, 1979), 亚历山大提供了设计公共和私人生活空间的模式目录。这里是一个典型的例子: 窗口位置
大家喜欢靠近窗户的位子, 海湾窗口和大窗口用低窗台和舒适的椅子为他们草拟。一间没有这样地方的房间很少能让你感到舒服或舒适。
如果房间里没有窗户, 在这样房间里的人将有可能做出下列抉择:
(1) 舒适地坐下来,
(2) 要充足的阳光。
显然, 如果舒适的地方-那些你最想坐的房间-远离窗户, 没有办法克服这一冲突。
因此，在每一天你花任何时间的房间里, 至少要把一个窗户变成一个 '窗口'。(图 3)
图3.窗口位置
在亚历山大的模式分类和软件模式的分类中，每个模式都遵循特定的格式。这些模式首先描述背景，即引发设计问题的情况；然后, 问题被解释, 通常作为一组相互冲突的力量。最后, 该解决方案显示了一种平衡这些力量的配置。
在 '窗口位置' 模式中, 背景是在白天花费任何时间长度的房间。冲突的力量是, 你想舒适的坐下, 又想拥有充足的阳光。解决方案是制作一个 '窗口位置'。
在 '模型-视图-控制器' 模式下, 我们将在下一节中描述, 背景是一个用户界面系统, 它提供信息并接收用户输入。有好几股力量。可能有多个可视表示形式的相同数据需要一起更新。例如, 可视表示形式可能会改变以适应各种观感标准。例如, 交互机制可能会发生变化, 以支持声音命令。解决方案是将职责分配到三个独立的交互组件中: 模型、视图和控制器。
模型-视图-控制器模式不是 AWT 和 Swing 设计中唯一使用的模式。这里有几个额外例子:
bull;容器和组件是 '组合（composite）' 模式
bull;带滚动条的面板是“装饰器（decorator）“模式
bull;布局管理器是“策略（strategy）“模式
设计模式的一个重要方面是它们成为文化的一部分。世界各地的程序员都知道你的意思, 当你谈论的模型-viewcontroller模式或装饰模式。因此, 模式成为讨论设计问题的有效方法。
流
在Java API中，我们可以读取一个字节序列的对象称为输入流。一个我们可以写一个字节序列的对象叫做o u t p u t r e a m。字节序列的这些源和目的地可以是而且通常是文件，但是
全文共6657字，剩余内容已隐藏，支付完成后下载完整资料
资料编号：[9196]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
