没有合适的资源?快使用搜索试试~ 我知道了~
C++ Why CPP Not Just an OOPL
需积分: 0 1 下载量 94 浏览量
2009-11-28
02:34:21
上传
评论
收藏 53KB PDF 举报
温馨提示
试读
13页
Why CPP Not Just an OOPL ?
资源详情
资源评论
资源推荐
Why C
++
is not just an Object-Oriented Programming Language
Bjarne Stroustrup
AT&T Bell Laboratories
Murray Hill, New Jersey 07974
ABSTRACT
C
++
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
C
++
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,
C
++
, 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页未读,继续阅读
Andy___Du
- 粉丝: 0
- 资源: 3
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功
评论0