面向对象开发_面向对象开发资源-CSDN文库

面向对象

需积分: 17 33 浏览量 2018-11-06 20:24:26 上传评论收藏 67KB PDF 举报

资源详情

资源评论

What is ‘‘Object-Oriented Programming’’? (1991 revised version)

Bjarne Stroustrup

AT&T Bell Laboratories

Murray Hill, New Jersey 07974

ABSTRACT

‘‘Object-Oriented Programming’’ and ‘‘Data Abstraction’’ have become very com-

mon terms. Unfortunately, few people agree on what they mean. I will offer informal

definitions that appear to make sense in the context of languages like Ada, C

, Modula-

2, Simula, and Smalltalk. The general idea is to equate ‘‘support for data abstraction’’

with the ability to define and use new types and equate ‘‘support for object-oriented pro-

gramming’’ with the ability to express type hierarchies. Features necessary to support

these programming styles in a general purpose programming language will be discussed.

The presentation centers around C

but is not limited to facilities provided by that lan-

guage.

1 Introduction

Not all programming languages can be ‘‘object oriented’’. Yet claims have been made to the effect that

APL, Ada, Clu, C

, LOOPS, and Smalltalk are object-oriented programming languages. I have heard dis-

cussions of object-oriented design in C, Pascal, Modula-2, and CHILL. Could there somewhere be propo-

nents of object-oriented Fortran and Cobol programming? I think there must be. ‘‘Object-oriented’’ has in

many circles become a high-tech synonym for ‘‘good’’, and when you examine discussions in the trade

press, you can find arguments that appear to boil down to syllogisms like:

Ada is good

Object oriented is good

-----------------------------------

Ada is object oriented

This paper presents one view of what ‘‘object oriented’’ ought to mean in the context of a general purpose

programming language.

§2 Distinguishes ‘‘object-oriented programming’’ and ‘‘data abstraction’’ from each other and from

other styles of programming and presents the mechanisms that are essential for supporting the vari-

ous styles of programming.

§3 Presents features needed to make data abstraction effective.

§4 Discusses facilities needed to support object-oriented programming.

§5 Presents some limits imposed on data abstraction and object-oriented programming by traditional

hardware architectures and operating systems.

Examples will be presented in C

. The reason for this is partly to introduce C

and partly because C

one of the few languages that supports both data abstraction and object-oriented programming in addition to

traditional programming techniques. Issues of concurrency and of hardware support for specific higher-

level language constructs are ignored in this paper.

- 2 -

2 Programming Paradigms

Object-oriented programming is a technique for programming

–

a paradigm for writing ‘‘good’’ pro-

grams for a set of problems. If the term ‘‘object-oriented programming language’’ means anything it must

mean a programming language that provides mechanisms that support the object-oriented style of program-

ming well.

There is an important distinction here. A language is said to support a style of programming if it pro-

vides facilities that makes it convenient (reasonably easy, safe, and efficient) to use that style. A language

does not support a technique if it takes exceptional effort or exceptional skill to write such programs; it

merely enables the technique to be used. For example, you can write structured programs in Fortran, write

type-secure programs in C, and use data abstraction in Modula-2, but it is unnecessarily hard to do because

these languages do not support those techniques.

Support for a paradigm comes not only in the obvious form of language facilities that allow direct use

of the paradigm, but also in the more subtle form of compile-time and/or run-time checks against uninten-

tional deviation from the paradigm. Type checking is the most obvious example of this; ambiguity detec-

tion and run-time checks can be used to extend linguistic support for paradigms. Extra-linguistic facilities

such as standard libraries and programming environments can also provide significant support for para-

digms.

A language is not necessarily better than another because it possesses a feature the other does not.

There are many example to the contrary. The important issue is not so much what features a language pos-

sesses but that the features it does possess are sufficient to support the desired programming styles in the

desired application areas:

[1] All features must be cleanly and elegantly integrated into the language.

[2] It must be possible to use features in combination to achieve solutions that would otherwise have

required extra separate features.

[3] There should be as few spurious and ‘‘special purpose’’ features as possible.

[4] A feature should be such that its implementation does not impose significant overheads on programs

that do not require it.

[5] A user need only know about the subset of the language explicitly used to write a program.

The last two principles can be summarized as ‘‘what you don’t know won’t hurt you.’’ If there are any

doubts about the usefulness of a feature it is better left out. It is much easier to add a feature to a language

than to remove or modify one that has found its way into the compilers or the literature.

I will now present some programming styles and the key language mechanisms necessary for support-

ing them. The presentation of language features is not intended to be exhaustive.

2.1 Procedural Programming

The original (and probably still the most commonly used) programming paradigm is:

Decide which procedures you want;

use the best algorithms you can find.

The focus is on the design of the processing, the algorithm needed to perform the desired computation.

Languages support this paradigm by facilities for passing arguments to functions and returning values from

functions. The literature related to this way of thinking is filled with discussion of ways of passing argu-

ments, ways of distinguishing different kinds of arguments, different kinds of functions (procedures, rou-

tines, macros, ...), etc. Fortran is the original procedural language; Algol60, Algol68, C, and Pascal are

later inventions in the same tradition.

A typical example of ‘‘good style’’ is a square root function. It neatly produces a result given an argu-

ment. To do this, it performs a well understood mathematical computation:

double sqrt(double arg)

{

// the code for calculating a square root

}

- 3 -

void some_function()

{

double root2 = sqrt(2);

// ...

}

From a program organization point of view, functions are used to create order in a maze of algorithms.

2.2 Data Hiding

Over the years, the emphasis in the design of programs has shifted away from the design of procedures

towards the organization of data. Among other things, this reflects an increase in the program size. A set

of related procedures with the data they manipulate is often called a module. The programming paradigm

becomes:

Decide which modules you want;

partition the program so that data is hidden in modules.

This paradigm is also known as the ‘‘data hiding principle’’. Where there is no grouping of procedures

with related data the procedural programming style suffices. In particular, the techniques for designing

‘‘good procedures’’ are now applied for each procedure in a module. The most common example is a defi-

nition of a stack module. The main problems that have to be solved for a good solution are:

[1] Provide a user interface for the stack (for example, functions push() and pop()).

[2] Ensure that the representation of the stack (for example, a vector of elements) can only be accessed

through this user interface.

[3] Ensure that the stack is initialized before its first use.

Here is a plausible external interface for a stack module:

// declaration of the interface of module stack of characters

char pop();

void push(char);

const stack_size = 100;

Assuming that this interface is found in a file called stack.h, the ‘‘internals’’ can be defined like this:

#include "stack.h"

static char v[stack_size]; // ‘‘static’’ means local to this file/module

static char* p = v; // the stack is initially empty

char pop()

{

// check for underflow and pop

}

void push(char c)

{

// check for overflow and push

}

It would be quite feasible to change the representation of this stack to a linked list. A user does not

have access to the representation anyway (since v and p were declared static, that is local to the

file/module in which they were declared). Such a stack can be used like this:

- 4 -

#include "stack.h"

void some_function()

{

char c = pop(push(’c’));

if (c != ’c’) error("impossible");

}

Pascal (as originally defined) doesn’t provide any satisfactory facilities for such grouping: the only

mechanism for hiding a name from ‘‘the rest of the program’’ is to make it local to a procedure. This leads

to strange procedure nestings and over-reliance on global data.

C fares somewhat better. As shown in the example above, you can define a ‘‘module’’ by grouping

related function and data definitions together in a single source file. The programmer can then control

which names are seen by the rest of the program (a name can be seen by the rest of the program unless it

has been declared static). Consequently, in C you can achieve a degree of modularity. However, there

is no generally accepted paradigm for using this facility and the technique of relying on static declara-

tions is rather low level.

One of Pascal’s successors, Modula-2, goes a bit further. It formalizes the concept of a module, making

it a fundamental language construct with well defined module declarations, explicit control of the scopes of

names (import/export), a module initialization mechanism, and a set of generally known and accepted

styles of usage.

The differences between C and Modula-2 in this area can be summarized by saying that C only enables

the decomposition of a program into modules, while Modula-2 supports that technique.

2.3 Data Abstraction

Programming with modules leads to the centralization of all data of a type under the control of a type

manager module. If one wanted two stacks, one would define a stack manager module with an interface

like this:

class stack_id; // stack_id is a type

// no details about stacks or stack_ids are known here

stack_id create_stack(int size); // make a stack and return its identifier

destroy_stack(stack_id); // call when stack is no longer needed

void push(stack_id, char);

char pop(stack_id);

This is certainly a great improvement over the traditional unstructured mess, but ‘‘types’’ implemented this

way are clearly very different from the built-in types in a language. Each type manager module must define

a separate mechanism for creating ‘‘variables’’ of its type, there is no established norm for assigning object

identifiers, a ‘‘variable’’ of such a type has no name known to the compiler or programming environment,

nor do such ‘‘variables’’ do not obey the usual scope rules or argument passing rules.

A type created through a module mechanism is in most important aspects different from a built-in type

and enjoys support inferior to the support provided for built-in types. For example:

void f()

{

stack_id s1;

stack_id s2;

s1 = create_stack(200);

// Oops: forgot to create s2

char c1 = pop(s1,push(s1,’a’));

if (c1 != ’c’) error("impossible");

- 5 -

char c2 = pop(s2,push(s2,’a’));

if (c2 != ’c’) error("impossible");

destroy(s2);

// Oops: forgot to destroy s1

}

In other words, the module concept that supports the data hiding paradigm enables this style of program-

ming, but it does not support it.

Languages such as Ada, Clu, and C

attack this problem by allowing a user to define types that behave

in (nearly) the same way as built-in types. Such a type is often called an abstract data type†. The program-

ming paradigm becomes:

Decide which types you want;

provide a full set of operations for each type.

Where there is no need for more that one object of a type the data hiding programming style using mod-

ules suffices. Arithmetic types such as rational and complex numbers are common examples of user-

defined types:

class complex {

double re, im;

public:

complex(double r, double i) { re=r; im=i; }

complex(double r) { re=r; im=0; } // float->complex conversion

friend complex operator+(complex, complex);

friend complex operator-(complex, complex); // binary minus

friend complex operator-(complex); // unary minus

friend complex operator*(complex, complex);

friend complex operator/(complex, complex);

// ...

};

The declaration of class (that is, user-defined type) complex specifies the representation of a complex

number and the set of operations on a complex number. The representation is private; that is, re and im

are accessible only to the functions specified in the declaration of class complex. Such functions can be

defined like this:

complex operator+(complex a1, complex a2)

{

return complex(a1.re+a2.re,a1.im+a2.im);

}

and used like this:

complex a = 2.3;

complex b = 1/a;

complex c = a+b*complex(1,2.3);

// ...

c = -(a/b)+2;

Most, but not all, modules are better expressed as user defined types. For concepts where the ‘‘module

representation’’ is desirable even when a proper facility for defining types is available, the programmer can

declare a type and only a single object of that type. Alternatively, a language might provide a module

__________________

† I prefer the term ‘‘user-defined type’’: ‘‘Those types are not "abstract"; they are as real as int and float.’’

–

Doug McIlroy. An

alternative definition of abstract data types would require a mathematical ‘‘abstract’’ specification of all types (both built-in and user-

defined). What is referred to as types in this paper would, given such a specification, be concrete specifications of such truly abstract

entities.

剩余20页未读，继续阅读

评论收藏

内容反馈

面向对象开发

评论0

最新资源

面向对象开发

评论0

最新资源

相关推荐

侯捷面向对象开发

面向对象开发实践之路—C#版--源代码

面向对象开发实践之路：DELPHI版(带完整书签)

面向对象开发实践之路(Delphi版)

java开发面向对象（银行小项目）

财务管理信息系统的面向对象开发方法研究信息系统的面向对象开发方法研究

JAVA面向对象开发宠物商店系统

Cache面向对象开发教程.pdf

uml和面向对象开发

软件工程面向对象开发之瀑布开发模型

(第23讲) PHP面向对象开发的学习（七）

SAP ABAP OBJECT 面向对象开发 （IBM官方培训教程）

JAVA面向对象开发宠物商店系统源码整理

测试驱动的面向对象软件开发

面向对象开发案例-抽奖系统.zip

Asp.net简单留言板源码(采用面向对象开发)

面向对象开发的开源php商城

面向对象开发方法

delphi MVC模式开发 面向对象开发

vdhcoapp-windows-x86-64-installer 2.0.19

大麦抢票+源代码+辅助工具+详细文档教程

嵌入式，PL2303-win11驱动程序

aurora-v3.0.4s-release.exe

labview入门开发100实例及对应部分vi

Unityhub 国际版 Windows版本 下载时间：2022年9月9日 10:35

CANdb++Admin完整安装包

MC大龙老师新版scratch3.0编程素材（第四版）

蓝桥杯第十四届省赛真题源码

INFI75 Driver V2.exe

SAP ABAP OBJECT 面向对象开发（IBM官方培训教程）

delphi MVC模式开发面向对象开发

Unityhub 国际版 Windows版本下载时间：2022年9月9日 10:35