使用Fortran进行面向对象编程

需积分: 10 154 浏览量更新于2024-07-27 收藏 2.28MB PDF 举报

"面向对象编程通过FORTRAN" 面向对象编程（OOP）是一种现代软件开发方法，它强调数据和操作这些数据的方法（称为“对象”）的封装。FORTRAN，最初设计为一个强大的科学计算语言，从FORTRAN 90版本开始引入了面向对象的特性，以满足现代编程需求。"Object Oriented Programming via Fortran"这本书旨在帮助读者掌握如何利用FORTRAN 90或95来实现面向对象的编程方法。在FORTRAN中应用面向对象编程，意味着可以创建类（classes），定义数据结构和与之相关的操作。类是对象的模板，而对象则是类的实例，它们具有属性（数据成员）和行为（成员函数）。通过这种方式，FORTRAN程序员可以构造复杂的数据结构，并隐藏内部实现细节，提高代码的可读性和可维护性。本书不仅涵盖了OOP的核心概念，如继承、封装、多态和抽象，还介绍了FORTRAN的基础语法和良好的编程实践。对于已经熟悉FORTRAN的程序员，这本书是一个理想的过渡工具，可以帮助他们平滑地接纳OOP的思想。作者Ed Akin通过与MATLAB和C++的比较，突出展示了各种主题，使得不同背景的读者都能快速理解这些概念。书中包含大量交叉引用的例子，这些例子覆盖了OOP的各种应用场景，并且附带的CD-ROM提供了所有示例的完整代码，以便读者可以动手实践。这种实践性的学习方式对于理解和掌握FORTRAN中的OOP至关重要。面向对象的FORTRAN 200X（可能指的是FORTRAN 2003或2008标准）完全支持OOP特性，使得FORTRAN成为编写清晰、高效可执行代码的理想选择，特别是在科学计算和工程应用领域。通过这本书，读者将能够利用FORTRAN的全部功能，包括其最新的面向对象特性，来编写出更加模块化和易于管理的代码。

P1: FCH/SPH P2: FCH/SPH QC: FCH/TKJ T1: FCH

CB496-01 CB496-Akin September 13, 2002 15:51

4 Program Design

Generation

n+1

• • • • • •

Figure 1.1: Here, the game is played on an 8 × 8 square array, and the ﬁlled squares indicate the

presence of life. The arrows emanating from one cell radiate to its eight neighbors. The rules are

applied to the nth generation to yield the next. The row of three ﬁlled cells becomes a column of three,

for example. What is going to happen to this conﬁguration in the next generation?

sketched in Figure 1.1. They differ in the way that the software development and mainte-

nance are planned and implemented. Procedures may use objects, and objects usually use

procedures called methods. Usually the object-oriented code takes more planning and is

signiﬁcantly larger, but it is generally accepted to be easier to maintain. Today when one can

have literally millions of users active for years or decades, maintenance considerations are

very important.

1.2 Problem Deﬁnition

The problem the program is to solve must be well speciﬁed. The programmer must broadly

frame the program’s intent and context by answering several questions.

What must the program accomplish?

From operating the space shuttle to inverting a small matrix, some thought must be given

to how the program will do what is needed. In technical terms, we need to deﬁne the

algorithm employed in small-scale programs. In particular, numeric programs need to

consider well how calculations are performed. For example, ﬁnding the roots of a general

polynomial demands a numeric (non-closed form) solution. The choice of algorithm is

inﬂuenced by the variations in polynomial order and the accuracy demanded.

What inputs are required and in what forms?

Most programs interact with humans and other programs. This interaction needs to be

clearly speciﬁed as to what format the data will take and when the data need to be

requested or arrive.

What is the execution environment and what should be in the user interface?

Is the program a stand-alone program, calculating the quadratic formula for example,

or do the results need to be plotted? In the former case, simple user input is probably

all that is needed, but the programmer might want to write the program so that its key

components could be used in other programs. In the latter, the program probably needs

to be written so that it meshes well with some prewritten graphics environment.

What are the required and optional outputs, and what are their formats (printed, magnetic,

graphical, audio)?

In many cases, output takes two forms: interactive and archival. Interactive output means

that the programs results must be provided to the user or to other programs. The data

P1: FCH/SPH P2: FCH/SPH QC: FCH/TKJ T1: FCH

CB496-01 CB496-Akin September 13, 2002 15:51

1.2 Problem Deﬁnition 5

format must be deﬁned so that the user can quickly see or hear the programs results.

Archival results need to be stored on long-term media, such as disk, so that later inter-

pretation of the ﬁle’s contents is easy (recall the notion of being able to read tomorrow

what is written today) and the reading process is easy.

The answers to these questions help programmers organize their thoughts and can lead to

decisions about programming language and operating environment. At this point in the pro-

gramming process, the programmer should know what the program is to do and for whom

the program is written. We do not yet have a clear notion of how the program will accomplish

these tasks; that comes down the road. This approach to program organization and design

is known as top–down design. Here, broad program goals and context are deﬁned ﬁrst with

additional detail ﬁlled in as needed. This approach contrasts with bottom–up design, where

the detail is decided ﬁrst and then merged into a functioning whole. For programming,

top–design makes more sense, but you as well as professional programmers are frequently

lured into writing code immediately, which is usually motivated by the desire to get some-

thing running and ﬁgure out later how to organize it all. That approach is prompted by

expediency but usually winds up being more inefﬁcient than a more considered, top–down

approach that takes longer to get off the ground but has increased likelihood of working

more quickly. The result of deﬁning the programming problem is a speciﬁcation: how the

program is structured, what computations it performs, and how it should interact with the

user.

An Extended Example: The Game of Life

rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr

To illustrate how to organize and write a simple program, let us structure a program that

plays TheGameofLife. Conway's “Game of Life" was popularized in Martin Gardner's Math-

ematical Games column in the October 1970 and February 1971 issues of Scientific Amer-

ican. This game is an example of what is known in computer science as cellular automata.

An extensive description of the game can be found in The Recursive Universe by William

Poundstone (Oxford University Press, 1987).

The rules of the game are quite simple. Imagine a rectangular array of square cells that are

either empty (no living being present) or ﬁlled (a being lives there). As shown in Figure 1.1,

each cell has eight neighboring cells. At each tick of the clock, a new generation of beings

is produced according to how many neighbors surround a given cell.

If a cell is empty, ﬁll it if three of its neighboring cells are ﬁlled; otherwise, leave it empty.

If a cell is ﬁlled, it

dies of loneliness if it has zero or one neighbors,

continues to live if it has two or three neighbors, or

dies of overcrowding if it has more than three neighbors.

The programming task is to allow the user to “play the game" by letting him or her deﬁne

initial conﬁgurations, start the program, which applies the rules and displays each genera-

tion, and stop the game at any time the user wants, returning to the initialization stage so

that a new conﬁguration can be tried. To understand the program task, we as programmers

need to pose several questions, some of which might be

What computer(s) are preferred, and what kind of display facilities do they have?

Is the size of the array arbitrary or ﬁxed?

Am I the only programmer?

P1: FCH/SPH P2: FCH/SPH QC: FCH/TKJ T1: FCH

CB496-01 CB496-Akin September 13, 2002 15:51

6 Program Design

No matter how these questions are answered, we start by forming the program's basic out-

line. Here is one way we might outline the program in a procedural fashion.

1. Allow the user to initialize the rectangular array or quit the program.

2. Start the calculation of the next generation.

(a) Apply game rules to the current array.

(b) Generate a new array.

(d) Determine whether the user wants to stop or not.

i. If not, go back to 2a.

ii. If so, go to step 1.

Note how the idea of reusing the portion of the program that applies game rules arises

naturally. This idea is peculiar to programming languages, having no counterpart in prose

(it's like being told at the end of a chapter to reread it!). This kind of looping behavior also

occurs when we go back and allow the user to restart the program.

rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr

This kind of outline is a form of pseudocode:

∗

a programming–language-like expression

of how the program operates. Note that at this point, the programming process is language

independent. Thus, informal pseudocode allows us to determine the program’s broad struc-

ture. We have not yet resolved the issue of how, or if, the array should be displayed: Should

it be refreshed as soon as a generation is calculated, or should we wait until a ﬁnal state is

reached or a step limit is exceeded? Furthermore, if calculating each generation takes a fair

amount of time, our candidate program organization will not allow the user to stop the pro-

gram until a generation’s calculations have been ﬁnished. Consequently, we may, depending

on the speed of the computer, want to limit the size of the array. A more detailed issue is

how to represent the array internally. These issues can be determined later; programmers

frequently make notes at this stage about how the program would behave with this structure.

Informal pseudocode should remain in the ﬁnal program in the form of comments.

Writing a program’s outline is not a meaningless exercise. How the program will behave

is determined at that point. An alternative would be to ask the user how many generations

should be calculated and then calculate all generations and display the results as a movie,

allowing the user to go backward, play in slow motion, freeze-frame, and so forth. Our

outline will not allow such visual fun. Thus, programmers usually design several candidate

program organizations, understand the consequences of each, and determine which best

meets the speciﬁcations.

1.3 Modular Program Design

We now need to deﬁne what the routines are and how they are interwoven to archieve the

program’s goals. (We will deepen this discussion to include objects and messages when we

introduce object-oriented formulations in Sec. 1.7.) What granularity – how large should a

routine be – comes with programming experience and depends somewhat on the language

∗

The use of the word code is interesting here. It means program as both a noun and a verb: From the earliest

days of programming, what the programmer produced was called code, and what he or she did was “code

the algorithm.” The origin of this word is somewhat mysterious. It may have arisen as an analogy to Morse

code, which used a series of dots and dashes as an alternative to the alphabet. This code is tedious to read

but ideal for telegraphic transmission. A program is an alternate form of an algorithm better suited to

computation.

P1: FCH/SPH P2: FCH/SPH QC: FCH/TKJ T1: FCH

CB496-01 CB496-Akin September 13, 2002 15:51

1.3 Modular Program Design 7

Program

Main Control

Subprogram #2

Subprogram #1

Figure 1.2: Modular program organization relies on self-contained routines in which the passage of

data (or messages) from one to the other is very well deﬁned and each routine’s (or objects) role in the

program becomes evident.

used to express it. A program typically begins with a main segment that controls or directs the

solution of the problem by dividing it into subtasks (see Figure 1.2). Each of these may well

be decomposed into other routines. This stepwise reﬁnement continues as long as necessary

and as long as it beneﬁts program clarity and efﬁciency. This modular program design is the

key feature of modern programming design practice. Furthermore, routines can be tested

individually and replaced or rewritten as needed. Before actually writing each routine, a

job known in computer circles as the implementation, the program’s organization can be

studied: Will the whole satisfy design speciﬁcations? Will the program execute efﬁciently?

As the implementation proceeds, each routine’s interface is deﬁned: How does it interact

with its master – the routine that called it – and how are data exchanged between the two?

In some languages, this interface can be prototyped: the routine’s interface – what it expects

and what values it calculates – can be deﬁned and the whole program merged and compiled

to check for consistency without performing any calculations. In small programs, where you

can have these routine deﬁnitions easily ﬁtting onto one page, this prototyping can almost

be performed visually. In complex programs, where there may be hundreds or thousands of

routines, such prototyping really pays off. Once the interfaces begin to form, we ask whether

they make sense: Do they exchange information efﬁciently? Does each routine have the

information it needs, or should the program be reorganized so that data exchange can be

accomplished more efﬁciently?

From another viewpoint, you should develop a programming style that “hedges your

bets:” programs should be written in such a way that allows their components to be used in a

variety of contexts. Again, using a modular programming style, the fundamental components

of the calculation should be expressed as a series of subroutines or functions, the interweaving

of which is controlled by a main program that reads the input information and produces the

output. A modular program can have its components extracted and used in other programs

(program reuse) or interfaced to environments. So-called monolithic programs, which tend

not to use routines and express the calculation as a single, long-winded program, should not

be written.

We emphasize that this modular design process proceeds without actually writing

program statements. We use a programming-like language known as formal pseudocode to

express in prose what routines call others and how. This prose might reexpress a graphic

P1: FCH/SPH P2: FCH/SPH QC: FCH/TKJ T1: FCH

CB496-01 CB496-Akin September 13, 2002 15:51

8 Program Design

representation of program organization such as that shown in Figure 1.2. In addition,

expressing the program’s design in pseudocode eases the transition to program composi-

tion, the actual programming process. The components of formal pseudocode at this point

are few:

comments that we allow to include the original outline and to describe computational

details;

functions that express each routine, whether it be computational or concerned with the

user interface;

conditionals that express changing the ﬂow of a program; and

loops that express iteration.

Comments. A comment begins with a comment character, which in our pseudocode we

take to be the exclamation point

, and ends when the line ends. Comments can consume

an entire line or the right portion of some line.

! This is a comment: you can read it, but the computer won’t

statements

statement ! From the comment character to end of this line is a comment

statements

The statements cited in the lines above share the status of the sentence that characterizes

most written languages. They are made up of components speciﬁc to the syntax of the

programming language in use. For example, most programming books begin with a program

that does nothing but print “Hello world” on the screen (or other output device). The

pseudocode for this might have the following form:

! if necessary, include the device library

initiate my program, say main

send the character string ‘‘Hello world’’ to the output device library

terminate my program

Figure 1.3 illustrates this in three common languages beginning with F90. At this point

it is possible to say we are multilingual in computer languages. Here, too, we may note

that, unlike the other two languages shown, in Fortran, when we begin a speciﬁc type of

software construct, we almost always explicitly declare where we are ending its scope. Here

the construct pair was

program and end program, but the same style holds true for if and

end if pairs, for example. All languages have rules and syntax to terminate the scope of

some construct, but when several types of different constructs occur in the same program

segment, it may be unclear in which order they are terminating.

Functions. To express a program’s organization through its component routines we use

the notation of mathematical functions. Each program routine accepts inputs expressed as

arguments of a function, performs its calculations, and returns the computational results as

functional values.

output 1 = routine (input 1,...,input m)

call routine (input 1,..., input m, output 1,..., output n)

剩余359页未读，继续阅读

convection

粉丝: 0
资源: 2

使用Fortran进行面向对象编程

"面向对象编程方法及其程序设计方法

面向对象编程：通过Fortran 90-95实现

深入学习Fortran语言教程：从基础到进阶

C 程序设计教学课件：CHAPTER 1 Object-Oriented Programming.ppt

Introduction to Programming with Fortran

Parallel Programming in Fortran 95 using OpenMP

Introduction to Programming with Fortran 2nd Edition

An introduction to programming in Fortran 90

Introduction to Programming with Fortran 原版PDF

使用Fortran 95进行编程简介Introduction to Programming using Fortran 95

最新资源