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

需积分: 1 198 浏览量更新于2024-07-22 收藏 1.15MB PDF 举报

"Akin E. OOP via Fortran 90-95 是一本介绍如何在Fortran 90和95中实现面向对象编程（OOP）的书籍，作者是Ed Akin，来自Rice University的机械工程和材料科学部门。这本书的主要目标是教育读者如何在传统的科学计算语言Fortran中应用OOP的概念和技术。" 本书分为多个章节，深入探讨了程序设计和数据类型等关键主题。首先，第一章"Program Design"介绍了程序设计的基础，包括问题定义、模块化设计、程序组成、注释、语句、流程控制、函数、模块以及动态内存管理。这一章还讨论了程序评估和测试的重要性以及程序文档的编写。此外，作者提到了面向对象的形式化，这是OOP的核心概念。第二章"Data Types"讲解了Fortran中的内在数据类型和用户自定义数据类型。作者详细阐述了抽象数据类型和类的创建，这些是实现OOP的关键组成部分。通过实例和练习，读者可以学习如何有效地利用这些数据类型来构造复杂的数据结构。第三章"Object Oriented Programming Concepts"深入到OOP的核心概念，如封装、继承和多态性。作者通过一个Date、Person和Student类的例子，直观地展示了这些概念的运用。此外，书中还介绍了如何进行面向对象的数值计算，特别是通过一个RationalNumber类和操作符重载来说明。这部分内容旨在帮助读者理解如何在实际的计算问题中应用OOP。书中的每个章节都包含了丰富的练习题，旨在巩固所学知识并鼓励读者将理论应用于实践。通过这本书，读者不仅能够掌握Fortran 90-95的基本语法，还能学会如何用现代的OOP方法来增强其代码的可维护性和复用性，这对于在科学计算领域使用Fortran的开发者来说尤其重要。 "Akin E. OOP via Fortran 90-95"是一本宝贵的资源，它填补了Fortran与现代编程思想之间的空白，让传统科学计算语言也能实现面向对象的编程风格。对于那些希望在科研或工程计算中采用更高效、更结构化的编程方式的Fortran程序员来说，这是一本不可或缺的参考书。

scatter, 173

scope, 14

SELECT CASE statement1, 64

SELECTED

INT KIND, 23, 24

SELECTED

REAL KIND, 23, 24

selector symbol, 26, 29, 34

server, 18

short, 24

size, 12

SIZE intrinsic, 70, 90, 93, 159

Smalltalk, 18

sort, 87, 91, 93, 96, 127

bubble, 93

characters, 95

object, 97

objects, 95

strings, 95

sorting, 42

sparse vector, 49

sparse vector class, 183

speciﬁcation, 4

SQRT intrinsic, 27

square root, 27, 56, 70

stack, 89

STAT = variable, 75

statement, 2, 9

statement block, 12, 58

statements, 1

status

FILE, 76

IOSTAT =, 76

MODE, 76

OPENED=, 76

status checking, 161

STOP statement, 37

storage

column wise, 159

row wise, 159

string, 23, 56

adjust, 78

case change, 81

character number, 78

collating sets, 78

colon operator, 78

concatenate, 78

copy, 78

dynamic length, 77

from number, 81

functions, 78

length, 78

logic, 78

repeat, 78

scan, 78

to number, 81

trim, 78

verify, 78

strings, 77

strong typing, 53

struct, 53

structure, 23, 25, 33, 85

structure constructor, 26

structured programming, 13

submatrix, 175

subprogram, 69

recursive, 102

subroutine, 69, 70

subroutine code, 114

assign, 87

Change, 77

delete

Rational, 42

equal

Fraction, 87

equal

Integer, 42

exception

status, 76

in, 106

Integer

Sort, 96, 99

invert, 42

list, 42

List

Angle, 114

List

Great Arc, 114

List

Position, 114

List

Position Angle, 114

List

Pt to Pt, 114

lsq

ﬁt, 93

mult

Fraction, 87

Change, 77

out, 106

Print, 29

Date, 37

DOB, 37

DOD, 37

DOM, 37

GPA, 37

Name, 37

Sex, 37

readData, 93, 101

read

Date, 37

Read

Position Angle, 114

reduce, 42

set

DOB, 37

set

DOD, 37

set

DOM, 37

set

Latitude, 114

set

Longitude, 114

simple

arithmetic, 56

Sort

Reals, 94

Sort

String, 95



2002 J.E. Akin 11

Chapter 1

Program Design

1.1 Introduction

The programming process is similar in approach and creativity to writing a paper. In composition, you

are writing to express ideas; in programming you are expressing a computation. Both the programmer

and the writer must adhere to the syntactic rules (grammar) of a particular language. In prose, the funda-

mental idea-expressing unit is the sentence; in programming, two units

statements and comments are

available.

Standing back, composition from technical prose to ﬁction should be organized broadly, usually

through an outline. The outline should be expanded as the detail is elaborated, and the whole re-examined

and re-organized when structural or creative ﬂaws arise. Once the outline settles, you begin the actual

composition process, using sentences to weave the fabric your outline expresses. Clarity in writing

occurs when your sentences, both internally and globally, communicate the outline succinctly and clearly.

We stress this approach here, with the aim of developing a programming style that produces efﬁcient

programs that humans can easily understand.

To a great degree, no matter which language you choose for your composition, the idea can be ex-

pressed with the same degree of clarity. Some subtleties can be better expressed in one language than

another, but the fundamental reason for choosing your language is your audience: People do not know

many languages, and if you want to address the American population, you had better choose English

over Swahili. Similar situations happen in programming languages, but they are not nearly so complex

or diverse. The number of languages is far fewer, and their differences minor. Fortran is the oldest lan-

guage among those in use today. C and C++ differ from it somewhat, but there are more similarities

than not. M

ATLAB’s language, written in C and Fortran, was created much later than these two, and its

structure is so similar to the others that it can be easily mastered. The C++ language is an extension of

the C language that places its emphasis on object oriented programming (OOP) methods. Fortran added

object oriented capabilities with its F90 standard, and additional enhancements for parallel machines

were issued with F95. The Fortran 2000 standard is planned to contain more user-friendly constructs for

polymorphism and will, thus, enhance its object-oriented capabilities. This creation of a new language

and its similarity to more established ones are this book’s main points: More computer programming lan-

guages will be created during your career, but these new languages will probably not be much different

than ones you already know. Why should new languages evolve? In M

ATLAB’s case, it was the desire to

express matrix-like expressions easily that motivated its creation. The difference between M

ATLAB and

Fortran 90 is inﬁnitesimally small compare to the gap between English and Swahili.

An important difference between programming and composition is that in programming you are writ-

ing for two audiences: people and computers. As for the computer audience, what you write is “read” by

interpreters and compilers speciﬁc to the language you used. They are very rigid about syntactic rules,

and perform exactly the calculations you say. It is like a document you write being read by the most de-

tailed, picky person you know; every pronoun is questioned, and if the antecedent is not perfectly clear,

then they throw up their hands, rigidly declaring that the entire document cannot be understood. Your

picky friend might interpret the sentence “Pick you up at eight” to mean that you will literally lift him or

her off the ground at precisely 8 o’clock, and then demand to know whether the time is in the morning or



2001 J.E. Akin 1

afternoon and what the date is.

Humans demand even more from programs. This audience consists of two main groups, whose goals

can conﬂict. The larger of the two groups consists of users. Users care about how the program presents

itself, its user interface, and how quickly the program runs, how efﬁcient it is. To satisfy this audience,

programmers may use statements that are overly terse because they know how to make the program more

readable by the computer’s compiler, enabling the compiler to produce faster, but less human-intelligible

program. This approach causes the other portion of the audience

programmers to boo and hiss. The

smaller audience, of which you are also a member, must be able to read the program so that they can

enhance and/or change it. A characteristic of programs, which further distinguishes it from prose, is

that you and others will seek to modify your program in the future. For example, in the 1960s when

the ﬁrst version of Fortran was created, useful programs by today’s standards (such as matrix inversion)

were written. Back then, the user interface possibilities were quite limited, and the use of visual displays

was limited. Thirty years later, you would (conceivably) want to take an old program, and provide a

modern user interface. If the program is structurally sound (a good outline and organized well) and is

well-written, re-using the “good” portions is easy accomplished.

The three-audience situation has prompted most languages to support both computer-oriented and

human-oriented “prose”. The program’s meaning is conveyed by statements, and is what the computer

interprets. Humans read this part, which in virtually all languages bears a strong relationship to mathe-

matical equations, and also read comments. Comments are not read by the computer at all, but are there

to help explain what might be expressed in a complicated way by programming language syntax. The

document or program you write today should be understandable tomorrow, not only by you, but also by

others. Sentences and paragraphs should make sense after a day or so of gestation. Paragraphs and larger

conceptual units should not make assumptions or leaps that confuse the reader. Otherwise, the document

you write for yourself or others served no purpose. The same is true with programming; the program’s

organizationshould be easy to follow and the way you write the program, using both statements and com-

ments, should help you and others understand how the computation proceeds. The existence of comments

permits the writer to directly express the program’s outline in the program to help the reader comprehend

the computation.

These similarities highlightthe parallels between composition and programming. Differencesbecome

evident because programming is, in many ways, more demanding than prose writing. On one hand, the

components and structure of programming languages are far simpler than the grammar and syntax of any

verbal or written language. When reading a document, you can ﬁgure out the misspelled words, and not

be bothered about every little imprecision in interpreting what is written. On the other, simple errors, akin

to misspelled words or unclear antecedents, can completely obviate a program, rendering it senseless or

causing it to go wildly wrong during execution. For example, there is no real dictionary when it comes

to programming. You can deﬁne variable names containing virtually any combination of letters (upper

and lower case), underscores, and numbers. A typographical error in a variable’s name can therefore

lead to unpredictable program behavior. Furthermore, computer execution speeds are becoming faster

and faster, meaning that increasingly complex programs can run very quickly. For example, the program

(actually groups of programs) that run NASA’s space shuttle might be comparable in size to Hugo’s Les

Mis

erables, but its complexity and immediate importance to the “user” far exceeds that of the novel.

As a consequence, program design must be extremely structured, having the ultimate intentions of

performing a speciﬁc calculation efﬁciently with attractive, understandable, efﬁcient programs. Achiev-

ing these general goals means breaking the program into components, writing and testing them separately,

then merging them according to the outline. Toward this end, we stress modular programming. Modules

can be on the scale of chapters or paragraphs, and share many of the same features. They consist of a se-

quence of statements that by themselves express a meaningful computation. They can be merged to form

larger programs by specifying what they do and how they interface to other packages of software. The

analogy in prose is agreeing on the character’s names and what events are to happen in each paragraph

so that events happen to the right people in the right sequence once the whole is formed. Modules can be

re-used in two ways. As with our program from the 1960s, we would “lift” the matrix inversion routine

and put a different user interface around it. We can also re-use a routine within a program several times.

For example, solving the equations of space ﬂight involves the inversion of many matrices. We would



2001 J.E. Akin 2

want our program to use the matrix inversion routine over and over, presenting it with a different matrix

each time.

The fundamental components of good program design are

1. Problem deﬁnition, leading to a program speciﬁcation

2. Modular program design, which reﬁnes the speciﬁcation

3. Module composition, which translates speciﬁcation into executable program

4. Module/program evaluation and testing, during which you reﬁne the program and ﬁnd errors

5. Program documentation, which pervades all other phases

The result of following these steps is an efﬁcient, easy-to-use program that has a user’s guide (how does

someone else run your program) and internal documentation so that other programmers can decipher the

algorithm.

Today it is common in a university education to be required to learn at least one foreign language.

Global interactions in business, engineering, and government make such a skill valuable to one’s career.

So it is in programming. One often needs to be able to read two or three programming languages

even

if you compose programs in only one language. It is common for different program modules, in different

languages, to be compiled separately and then brought together by a “linker” to form a single executable.

When something goes wrong in such a process it is usually helpful to have a reading knowledge of the

programming languages being used.

When composing to express ideas there are, at least, two different approaches to consider: poetry and

prose. Likewise, in employing programming languages to create software there are distinctly different

approaches available. The two most common ones are “procedural programming” and “object-oriented

programming.” The two approaches are conceptually sketched in Fig. 1.1. They differ in the way that the

software development and maintenance 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/or 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

pre-written graphics environment.



2001 J.E. Akin 3

剩余300页未读，继续阅读

liuwmath

粉丝: 0
资源: 1

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

Akin教授的Fortran90编程

edjpgcom|图片中插入一句话

Error running CommonApplication. Command line is too long. Shorten the command line via JAR manifest or via a classpath file and rerun.

荧光自动化细胞计数仪的参考文献综述

out = new PrintWriter(new OutputStreamWriter(conn.getOutputStream(), "UTF-8"));这句代码抛FileNotFoundException原因可能是什么

bigdecimal 加减

@DefaultValue引用什么包

Java中线程之间的通信-(子线程获得主线程的方式)以及代码例子

'@DefaultValue' not applicable to field

org.springframework.boot.context.properties.bind.DefaultValue 值

最新资源