Por Que c++

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++ deliberately differs from languages designed to support a single way of writing programs. This paper briefly presents key programming styles directly supported by C++ and argues thatthe 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 IntroductionThere are many tools and techniques that can help in our effort to build useful, economical, and maintainable 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 andimplementation of systems. A programming language is just one of the means by which we try to achieve our goals. The definition of ‘‘object-oriented programming’’ 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 isclearly 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,’’ ‘‘objectoriented technology,’’ etc., is, however, a burning issue for people who want to turn the oft-repeated promises made fortechniques 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 technology?,’’ what benefits can be expected from it? at what risks?, how do those techniques, benefits, and risks compare with those associated with alternatives? A systems builder trying to explain to an accountant whymoney should be spent for tools supporting object-oriented techniques needs more than a statement to the effect that ‘‘object-oriented is great’’ or that ‘‘really great techniques are really objectoriented.’’ 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 logically coherent semi-mathematical treatment of thesubject of direct practical use. We need to define ‘‘object-oriented’’ to be something specific so that we can point out specific benefits 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 gooddefinition 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 uncommon to find programs that apply techniques usually deemed object-oriented extensively or even exclusively, yet are hard to comprehend, hard to maintain, and perform abysmally. Such...