whyC++isnotjustanObject-OrientedProgrammingLanguage资源-CSDN文库

Object-Oriented

需积分: 13 123 浏览量 2010-08-25 21:32:16 上传评论收藏 52KB PDF 举报

资源推荐

资源详情

资源评论

Why C

is not just an Object-Oriented Programming Language

Bjarne Stroustrup

AT&T Bell Laboratories

Murray Hill, New Jersey 07974

ABSTRACT

directly supports a variety of programming styles. In this, C

deliber-

ately differs from languages designed to support a single way of writing pro-

grams. This paper briefly presents key programming styles directly supported by

and argues that the support for multiple styles is one of its major strengths.

The styles presented include: traditional C-style, concrete classes, abstract

classes, traditional class hierarchies, abstract classes and class hierarchies, and

generic programming. To provide a context for this overview, I discuss criteria

for a reasonable and useful definition of ‘‘object-oriented programming.’’

1 Introduction

There are many tools and techniques that can help in

our effort to build useful, economical, and maintain-

able systems. To complete ambitious and complex

projects, we rely on a wide variety of techniques and

tools that must work together.

The title of this paper singles out a programming

language†. However, the real topic is programming,

or if you prefer a longer formulation, the design and

implementation of systems. A programming lan-

guage is just one of the means by which we try to

achieve our goals.

The definition of ‘‘object-oriented program-

ming’’ is no longer a popular topic of discussion at

major conferences. A practical definition of

________________

† This paper is primarily based on an invited talk with the same title given at OOPSLA’95 in Austin Texas. The style of this paper is

clearly affected by its origins as a relatively short talk. I would have preferred this paper to be either much longer or much shorter,

but I did not have the time to do either.

‘‘object-oriented programming,’’ ‘‘object-oriented

analysis,’’ ‘‘object-oriented design,’’ ‘‘object-

oriented technology,’’ etc., is, however, a burning

issue for people who want to turn the oft-repeated

promises made for techniques and languages called

‘‘object-oriented’’ into reality in everyday projects.

It has become a practical rather than academic topic

of discussion. What is ‘‘object-oriented technol-

ogy?,’’ what benefits can be expected from it? at

what risks?, how do those techniques, benefits, and

risks compare with those associated with alterna-

tives?

A systems builder trying to explain to an accoun-

tant why money should be spent for tools supporting

object-oriented techniques needs more than a state-

ment to the effect that ‘‘object-oriented is great’’ or

that ‘‘really great techniques are really object-

oriented.’’ You simply cannot ask someone to bet

their company’s future on vague promises phased in

ill-defined terms. Nor is a well-polished and logi-

cally coherent semi-mathematical treatment of the

subject of direct practical use.

We need to define ‘‘object-oriented’’ to be some-

thing specific so that we can point out specific bene-

fits and risks associated with its use. We must also

be specific about what is not object-oriented, and

what benefits and lack of benefits we can expect

from various non-object-oriented techniques.

Consequently, this paper starts out discussing

what makes a good definition of ‘‘object-oriented.’’

Next, I present a range of useful techniques which

may or may not be object oriented and discuss their

advantages and disadvantages.

2 Defining ‘‘Object-oriented’’

To be useful and intellectually honest, a definition of

‘‘object-oriented’’ must

[1] not be a mere synonym for ‘‘good,’’

[2] not exclude most accepted meanings,

[3] have a firm historical basis,

[4] exclude something.

Not everything good is object- oriented, and not

everything object-oriented is good. I think I can

support both claims from experience. I have seen

examples of the latter often enough: it is not uncom-

mon to find programs that apply techniques usually

deemed object-oriented extensively or even exclu-

sively, yet are hard to comprehend, hard to maintain,

and perform abysmally. Such examples occur in

every programming language. But then, of course,

some people respond ‘‘that just proves that the pro-

gram wasn’t truly object-oriented.’’ To which the

answer must be that either the term has become

meaningless or there must be something good

beyond what is called ‘‘object-oriented.’’

On the other hand, when we define ‘‘object-

oriented,’’ we must not be too exclusive. Object-

oriented programming is a broad intellectual disci-

pline, not the mere use of specific language features.

Attempts to define ‘‘object-oriented’’ to mean

‘‘what I’m selling’’ are not uncommon, but are fun-

damentally sleazy.

Any definition of ‘‘object-oriented’’ should be

historically reasonable. Words are only useful for

communication, really only mean something, if we

agree on a meaning for them. There are several

plausible, logically coherent, and mutually

contradictory definitions of ‘‘object oriented’’ in

use. However, the mainstream usage stems directly

from the ideas pioneered by programming language

Simula and the design techniques it was developed

to support. The communities of programmers and

designers centered around languages such as C

CLOS, Eiffel, Object Pascal, and Smalltalk have

contributed much to this tradition.

A meaningful definition of any concept must

exclude something.

3 A Broad Definition of ‘‘Object-oriented’’

Given these general criteria for a definition of

’’object-oriented’’ you can find several plausible

candidates, and several communities have their own

definitions. However, I suggest we stick to the tradi-

tional definition of object-oriented used within broad

communities of programmers. A language or tech-

nique is object-oriented if and only if it directly sup-

ports:

[1] Abstraction

–

providing some form of classes

and objects.

[2] Inheritance

–

providing the ability to build

new abstractions out of existing ones.

[3] Run-time polymorphism

–

providing some

form of run-time binding.

This definition includes all major languages com-

monly referred to as object-oriented: Ada95, Beta,

, CLOS, Eiffel, Simula, Smalltalk, and many

other languages fit this definition. Classical pro-

gramming languages without classes, such as C, For-

tran4, and Pascal, are excluded. Languages that lack

direct support for inheritance or run-time binding,

such as Ada88 and ML are also excluded.

ML is a good example of something that is good

but not object-oriented. I like ML; it is an interest-

ing, innovative, and powerful language, but it is

functional rather than object-oriented and its poly-

morphism is resolved at compile time rather than at

run-time. Thus, saying that ML isn’t object-oriented

is not a criticism, it’s an observation about defini-

tions and the nature of ML.

Techniques and tools are object-oriented if and

only if they support the use of object-oriented pro-

gramming. For example, a design method is object-

oriented if its regular and proper use leads to

programs that exploit abstraction, inheritance, and

polymorphism where appropriate. I strongly prefer

design methods that directly and naturally support

the use of at least one of the major object-oriented

languages supporting in ways that exploit its features

in an idiomatic way.

For example, it is often possible to simplify

application code by hiding objects with different rep-

resentations and different implementation details

behind a common ‘‘abstract’’ interface (see §6.4 and

§6.6). Conversely, the implementation of related

concepts can often be greatly simplified by exploit-

ing commonality through inheritance (see §6.5 and

§6.6). A major purpose of design methods and the

CASE tools that commonly support them is to make

design simpler, more regular, and more predictable.

Thus, to earn the label ‘‘object-oriented,’’ a design

method must regularly and predictably help the dis-

covery of commonality that can be exploited in these

ways. Ideally, an object-oriented design method

must strongly encourage the expression of this com-

monality using the most appropriate facilities in one

or more of the languages supporting object-oriented

programming. Minimally, the method and its sup-

porting tools must not be a hindrance to the use of

object-oriented facilities in the programming lan-

guage used to implement the design. Much confu-

sion arise because not every design method that

claims to be object-oriented does that.

Please remember that I’m looking for a practical

understanding of the notion of ‘‘object-oriented’’

rather than a formal definition. A formal definition

is useful, indeed it may be essential. However, to be

relevant, a formal definition must match a coherent

view of what the formal definition is meant to spec-

ify precisely.

4 Purity

There has been much debate about ‘‘purity,’’ in the

context of languages supporting object-oriented pro-

gramming. In my opinion, much of that discussion

is confused by the

–

often unstated

–

assumption

that not only does ‘‘object-oriented’’ imply ’’good,’’

but also by the further assumption that only

‘‘object-oriented’’ features are good. Consequently,

it is

–

wrongly

–

assumed that a language that

provides features deemed non-object-oriented must

be worse than a language that does not. People who

like a language to support classes as part of a hierar-

chy only and functions/methods attached to one spe-

cific class only often call such a language ‘‘a pure

object-oriented language.’’ If we don’t like the idea

of restricting the definition of classes and functions

that way we can call such a language ‘‘just an

object-oriented programming language.’’

I prefer to have more facilities available than can

be provided by methods defined on classes within a

single hierarchy. A lot of good design goes beyond

that relatively narrow domain. Incidentally, I have

come to dislike the adjective ‘‘hybrid’’ as used to

distinguish ‘‘pure’’ object-oriented systems from

others. Too often, ‘‘hybrid’’ is used in a prejudicial

manner. If I must apply a descriptive label, I use the

phrase ‘‘multi-paradigm language’’ to describe C

4.1 Use of Language Features

Even when all the features required to support

object-oriented programming are available, you

don’t need to use them all the time. Some classes

just don’t belong in a hierarchy and some functions

don’t belong to any particular object.

The key to maintainable, efficient, and evolvable

programs isn’t particular language features. It is the

ability to develop concepts needed for a solution and

to express them clearly in a program. Language fea-

tures exist to make such expression simple and

direct.

Object-oriented programming can be done in a

language lacking one or more of the features

required to directly support object-oriented program-

ming. However, doing so is unnecessarily difficult,

very difficult to support with tools, and often pro-

hibitively expensive.

Furthermore, there are things that can’t be

expressed directly using only the ‘‘pure’’ object-

oriented constructs mentioned above. For example,

some entities belong together, but their relationships

are not hierarchal. Some entities simply do not obey

the rules of a particular object-oriented language.

Some things that you build in an object-oriented

world are manipulated from the outside so that it is

difficult to make guarantees about the way they are

used.

剩余12页未读，继续阅读

评论收藏

内容反馈

linusyue

粉丝: 122
资源: 14

why C++ is not just an Object-Oriented Programming Language

最新资源

why C++ is not just an Object-Oriented Programming Language

Object-Oriented Programming in C++源程序

Deciphering Object-Oriented Programming with C++

Object - Oriented Programming C++ Simplified

Introduction to Object-Oriented Programming Using C++

A Guide to MATLAB Object-Oriented Programming

Object- Oriented Programming with Ansi-C

matlab面向对象编程教程-A Guide to MATLAB Object-Oriented Programming - Register, CRC 2007.rar

Object-Oriented Analysis and Design for Information Systems

Inside Cocoa- Object-Oriented Programming And The Objective-C Language

[PrenticeHall]Introduction_To_Object-Oriented_Programming_Using_C++.zip

面向对象编程和Objective-C语言Object-Oriented Programming And The Objective-C Language

Object – Oriented Programming C++ Simplified 无水印pdf

Real time C++ Efficient Object-Oriented and Template Microcontroller Programming

Object-Oriented Software Construction 2nd

Component Software - Beyond Object-Oriented Programming 2nd Edition

Inside The C++ Object Model 英文版

Inside the C++ object model 高清英文版

beginning programming with c++

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

Real-Time C++ Efficient Object-Oriented and Template Microcontroller Programming

Object-Oriented Programming in C++ by Robert Lafore

(珍贵资源)Object-Oriented Programming And The Objective-C Language

Object-Oriented Programming Using C++.pdf

C++ For Dummies

面向对象C编程

The.Dart.Programming.Language.03219277

Ruby Cookbook: Recipes for Object-Oriented Scripting

Inside the C++ object model

最新资源