Object-oriented programming 1
Object-oriented programming
Object-oriented programming (OOP) is a programming paradigm using "objects" – usually instances of a class –
consisting of data fields and methods together with their interactions – to design applications and computer
programs. Programming techniques may include features such as data abstraction, encapsulation, messaging,
modularity, polymorphism, and inheritance. Many modern programming languages now support OOP, at least as an
option.
Overview
An object-oriented program may be viewed as a collection of interacting objects, as opposed to the conventional
model, in which a program is seen as a list of tasks (subroutines) to perform. In OOP, each object is capable of
receiving messages, processing data, and sending messages to other objects. Each object can be viewed as an
independent "machine" with a distinct role or responsibility. The actions (or "methods") on these objects are closely
associated with the object. For example, OOP data structures tend to "carry their own operators around with them"
(or at least "inherit" them from a similar object or class) - except when they have to be serialized.
Simple, non-OOP programs may be one "long" list of statements (or commands). More complex programs will often
group smaller sections of these statements into functions or subroutines each of which might perform a particular
task. With designs of this sort, it is common for some of the program's data to be 'global', i.e. accessible from any
part of the program. As programs grow in size, allowing any function to modify any piece of data means that bugs
can have wide-reaching effects.
In contrast, the object-oriented approach encourages the programmer to place data where it is not directly accessible
by the rest of the program. Instead, the data is accessed by calling specially written functions, commonly called
methods, which are either bundled in with the data or inherited from "class objects." These act as the intermediaries
for retrieving or modifying the data they control. The programming construct that combines data with a set of
methods for accessing and managing those data is called an object. The practice of using subroutines to examine or
modify certain kinds of data was also used in non-OOP modular programming, well before the widespread use of
object-oriented programming.
An object-oriented program will usually contain different types of objects, each type corresponding to a particular
kind of complex data to be managed or perhaps to a real-world object or concept such as a bank account, a hockey
player, or a bulldozer. A program might well contain multiple copies of each type of object, one for each of the
real-world objects the program is dealing with. For instance, there could be one bank account object for each
real-world account at a particular bank. Each copy of the bank account object would be alike in the methods it offers
for manipulating or reading its data, but the data inside each object would differ reflecting the different history of
each account.
Objects can be thought of as wrapping their data within a set of functions designed to ensure that the data are used
appropriately, and to assist in that use. The object's methods will typically include checks and safeguards that are
specific to the types of data the object contains. An object can also offer simple-to-use, standardized methods for
performing particular operations on its data, while concealing the specifics of how those tasks are accomplished. In
this way alterations can be made to the internal structure or methods of an object without requiring that the rest of the
program be modified. This approach can also be used to offer standardized methods across different types of objects.
As an example, several different types of objects might offer print methods. Each type of object might implement
that print method in a different way, reflecting the different kinds of data each contains, but all the different print
methods might be called in the same standardized manner from elsewhere in the program. These features become
especially useful when more than one programmer is contributing code to a project or when the goal is to reuse code
between projects.
Object-oriented programming 2
Object-oriented programming has roots that can be traced to the 1960s. As hardware and software became
increasingly complex, manageability often became a concern. Researchers studied ways to maintain software quality
and developed object-oriented programming in part to address common problems by strongly emphasizing discrete,
reusable units of programming logic. The technology focuses on data rather than processes, with programs composed
of self-sufficient modules ("classes"), each instance of which ("objects") contains all the information needed to
manipulate its own data structure ("members"). This is in contrast to the existing modular programming that had
been dominant for many years that focused on the function of a module, rather than specifically the data, but equally
provided for code reuse, and self-sufficient reusable units of programming logic, enabling collaboration through the
use of linked modules (subroutines).
History
The terms "objects" and "oriented" in something like the modern sense of object-oriented programming seem to
make their first appearance at MIT in the late 1950s and early 1960s. In the environment of the artificial intelligence
group, as early as 1960, "object" could refer to identified items (LISP atoms) with properties (attributes);[1][2] Alan
Kay was later to cite a detailed understanding of LISP internals as a strong influence on his thinking in 1966.[3]
Another early MIT example was Sketchpad created by Ivan Sutherland in 1960-61; in the glossary of the 1963
technical report based on his dissertation about Sketchpad, Sutherland defined notions of "object" and "instance"
(with the class concept covered by "master" or "definition"), albeit specialized to graphical interaction.[4] Also, an
MIT ALGOL version, AED-0, linked data structures ("plexes", in that dialect) directly with procedures, prefiguring
what were later termed "messages", "methods" and "member functions".[5][6]
Objects as a formal concept in programming were introduced in the 1960s in Simula 67, a major revision of Simula
I, a programming language designed for discrete event simulation, created by Ole-Johan Dahl and Kristen Nygaard
of the Norwegian Computing Center in Oslo.[7] Simula 67 was influenced by SIMSCRIPT and C.A.R. "Tony"
Hoare's proposed "record classes".[5][8] Simula introduced the notion of classes and instances or objects (as well as
subclasses, virtual methods, coroutines, and discrete event simulation) as part of an explicit programming paradigm.
The language also used automatic garbage collection that had been invented earlier for the functional programming
language Lisp. Simula was used for physical modeling, such as models to study and improve the movement of ships
and their content through cargo ports. The ideas of Simula 67 influenced many later languages, including Smalltalk,
derivatives of LISP (CLOS), Object Pascal, and C++.
The Smalltalk language, which was developed at Xerox PARC (by Alan Kay and others) in the 1970s, introduced
the term object-oriented programming to represent the pervasive use of objects and messages as the basis for
computation. Smalltalk creators were influenced by the ideas introduced in Simula 67, but Smalltalk was designed to
be a fully dynamic system in which classes could be created and modified dynamically rather than statically as in
Simula 67.[9] Smalltalk and with it OOP were introduced to a wider audience by the August 1981 issue of Byte
Magazine.
In the 1970s, Kay's Smalltalk work had influenced the Lisp community to incorporate object-based techniques that
were introduced to developers via the Lisp machine. Experimentation with various extensions to Lisp (like LOOPS
and Flavors introducing multiple inheritance and mixins), eventually led to the Common Lisp Object System (CLOS,
a part of the first standardized object-oriented programming language, ANSI Common Lisp), which integrates
functional programming and object-oriented programming and allows extension via a Meta-object protocol. In the
1980s, there were a few attempts to design processor architectures that included hardware support for objects in
memory but these were not successful. Examples include the Intel iAPX 432 and the Linn Smart Rekursiv.
In 1985, Bertrand Meyer produced the first design of the Eiffel language. Focused on software quality, Eiffel is
among the purely object-oriented languages, but differs in the sense that the language itself is not only a
programming language, but a notation supporting the entire software lifecycle. Meyer described the Eiffel software
development method, based on a small number of key ideas from software engineering and computer science, in
Object-oriented programming 3
Object-Oriented Software Construction. Essential to the quality focus of Eiffel is Meyer's reliability mechanism,
Design by Contract, which is an integral part of both the method and language.
Object-oriented programming developed as the dominant programming methodology in the early and mid 1990s
when programming languages supporting the techniques became widely available. These included Visual FoxPro
3.0,[10][11][12] C++, and Delphi. Its dominance was further enhanced by the rising popularity of graphical user
interfaces, which rely heavily upon object-oriented programming techniques. An example of a closely related
dynamic GUI library and OOP language can be found in the Cocoa frameworks on Mac OS X, written in
Objective-C, an object-oriented, dynamic messaging extension to C based on Smalltalk. OOP toolkits also enhanced
the popularity of event-driven programming (although this concept is not limited to OOP). Some feel that association
with GUIs (real or perceived) was what propelled OOP into the programming mainstream.
At ETH Zürich, Niklaus Wirth and his colleagues had also been investigating such topics as data abstraction and
modular programming (although this had been in common use in the 1960s or earlier). Modula-2 (1978) included
both, and their succeeding design, Oberon, included a distinctive approach to object orientation, classes, and such.
The approach is unlike Smalltalk, and very unlike C++.
Object-oriented features have been added to many existing languages during that time, including Ada, BASIC,
Fortran, Pascal, and others. Adding these features to languages that were not initially designed for them often led to
problems with compatibility and maintainability of code.
More recently, a number of languages have emerged that are primarily object-oriented yet compatible with
procedural methodology, such as Python and Ruby. Probably the most commercially important recent
object-oriented languages are Visual Basic.NET (VB.NET) and C#, both designed for Microsoft's .NET platform,
and Java, developed by Sun Microsystems. Both frameworks show the benefit of using OOP by creating an
abstraction from implementation in their own way. VB.NET and C# support cross-language inheritance, allowing
classes defined in one language to subclass classes defined in the other language. Developers usually compile Java to
bytecode, allowing Java to run on any operating system for which a Java virtual machine is available. VB.NET and
C# make use of the Strategy pattern to accomplish cross-language inheritance, whereas Java makes use of the
Adapter pattern .
Just as procedural programming led to refinements of techniques such as structured programming, modern
object-oriented software design methods include refinements such as the use of design patterns, design by contract,
and modeling languages (such as UML).
Fundamental features and concepts
A survey by Deborah J. Armstrong of nearly 40 years of computing literature identified a number of "quarks", or
fundamental concepts, found in the strong majority of definitions of OOP.[13]
Not all of these concepts are to be found in all object-oriented programming languages. For example, object-oriented
programming that uses classes is sometimes called class-based programming, while prototype-based programming
does not typically use classes. As a result, a significantly different yet analogous terminology is used to define the
concepts of object and instance.
Benjamin C. Pierce and some other researchers view as futile any attempt to distill OOP to a minimal set of features.
He nonetheless identifies fundamental features that support the OOP programming style in most object-oriented
languages:[14]
• Dynamic dispatch – when a method is invoked on an object, the object itself determines what code gets executed
by looking up the method at run time in a table associated with the object. This feature distinguishes an object
from an abstract data type (or module), which has a fixed (static) implementation of the operations for all
instances. It is a programming methodology that gives modular component development while at the same time
being very efficient.
Object-oriented programming 4
• Encapsulation (or multi-methods, in which case the state is kept separate)
•• Subtype polymorphism
• Object inheritance (or delegation)
• Open recursion – a special variable (syntactically it may be a keyword), usually called this or self, that
allows a method body to invoke another method body of the same object. This variable is late-bound; it allows a
method defined in one class to invoke another method that is defined later, in some subclass thereof.
Similarly, in his 2003 book, Concepts in programming languages, John C. Mitchell identifies four main features:
dynamic dispatch, abstraction, subtype polymorphism, and inheritance.[15] Michael Lee Scott in Programming
Language Pragmatics considers only encapsulation, inheritance and dynamic dispatch.[16]
Additional concepts used in object-oriented programming include:
• Classes of objects
• Instances of classes
• Methods which act on the attached objects.
•• Message passing
•• Abstraction
Decoupling
Decoupling refers to careful controls that separate code modules from particular use cases, which increases code
re-usability. A common use of decoupling in OOP is to polymorphically decouple the encapsulation (see Bridge
pattern and Adapter pattern) - for example, using a method interface which an encapsulated object must satisfy, as
opposed to using the object's class.
Formal semantics
There have been several attempts at formalizing the concepts used in object-oriented programming. The following
concepts and constructs have been used as interpretations of OOP concepts:
• coalgebraic data types [17]
• abstract data types (which have existential types) allow the definition of modules but these do not support
dynamic dispatch
• recursive types
•• encapsulated state
•• Inheritance
• records are basis for understanding objects if function literals can be stored in fields (like in functional
programming languages), but the actual calculi need be considerably more complex to incorporate essential
features of OOP. Several extensions of System F<: that deal with mutable objects have been studied;
[18] these
allow both subtype polymorphism and parametric polymorphism (generics)
Attempts to find a consensus definition or theory behind objects have not proven very successful (however, see
Abadi & Cardelli, A Theory of Objects [19][18] for formal definitions of many OOP concepts and constructs), and
often diverge widely. For example, some definitions focus on mental activities, and some on program structuring.
One of the simpler definitions is that OOP is the act of using "map" data structures or arrays that can contain
functions and pointers to other maps, all with some syntactic and scoping sugar on top. Inheritance can be performed
by cloning the maps (sometimes called "prototyping"). OBJECT:=>> Objects are the run time entities in an
object-oriented system. They may represent a person, a place, a bank account, a table of data or any item that the
program has to handle.
Object-oriented programming 5
OOP languages
Simula (1967) is generally accepted as the first language to have the primary features of an object-oriented language.
It was created for making simulation programs, in which what came to be called objects were the most important
information representation. Smalltalk (1972 to 1980) is arguably the canonical example, and the one with which
much of the theory of object-oriented programming was developed. Concerning the degree of object orientation, the
following distinctions can be made:
• Languages called "pure" OO languages, because everything in them is treated consistently as an object, from
primitives such as characters and punctuation, all the way up to whole classes, prototypes, blocks, modules, etc.
They were designed specifically to facilitate, even enforce, OO methods. Examples: Eiffel, Emerald.[20], JADE,
Obix, Scala, Smalltalk
• Languages designed mainly for OO programming, but with some procedural elements. Examples: C++, Java, C#,
VB.NET, Python.
• Languages that are historically procedural languages, but have been extended with some OO features. Examples:
Visual Basic (derived from BASIC), Fortran, Perl, COBOL 2002, PHP, ABAP.
• Languages with most of the features of objects (classes, methods, inheritance, reusability), but in a distinctly
original form. Examples: Oberon (Oberon-1 or Oberon-2) and Common Lisp.
• Languages with abstract data type support, but not all features of object-orientation, sometimes called
object-based languages. Examples: Modula-2 (with excellent encapsulation and information hiding), Pliant, CLU.
OOP in dynamic languages
In recent years, object-oriented programming has become especially popular in dynamic programming languages.
Python, Ruby and Groovy are dynamic languages built on OOP principles, while Perl and PHP have been adding
object oriented features since Perl 5 and PHP 4, and ColdFusion since version 5.
The Document Object Model of HTML, XHTML, and XML documents on the Internet have bindings to the popular
JavaScript/ECMAScript language. JavaScript is perhaps the best known prototype-based programming language,
which employs cloning from prototypes rather than inheriting from a class. Another scripting language that takes this
approach is Lua. Earlier versions of ActionScript (a partial superset of the ECMA-262 R3, otherwise known as
ECMAScript) also used a prototype-based object model. Later versions of ActionScript incorporate a combination of
classification and prototype-based object models based largely on the currently incomplete ECMA-262 R4
specification, which has its roots in an early JavaScript 2 Proposal. Microsoft's JScript.NET also includes a mash-up
of object models based on the same proposal, and is also a superset of the ECMA-262 R3 specification.
Design patterns
Challenges of object-oriented design are addressed by several methodologies. Most common is known as the design
patterns codified by Gamma et al.. More broadly, the term "design patterns" can be used to refer to any general,
repeatable solution to a commonly occurring problem in software design. Some of these commonly occurring
problems have implications and solutions particular to object-oriented development.
Inheritance and behavioral subtyping
It is intuitive to assume that inheritance creates a semantic "is a" relationship, and thus to infer that objects
instantiated from subclasses can always be safely used instead of those instantiated from the superclass. This
intuition is unfortunately false in most OOP languages, in particular in all those that allow mutable objects. Subtype
polymorphism as enforced by the type chec
本文档为【Object-oriented programming】,请使用软件OFFICE或WPS软件打开。作品中的文字与图均可以修改和编辑,
图片更改请在作品中右键图片并更换,文字修改请直接点击文字进行修改,也可以新增和删除文档中的内容。
该文档来自用户分享,如有侵权行为请发邮件ishare@vip.sina.com联系网站客服,我们会及时删除。
[版权声明] 本站所有资料为用户分享产生,若发现您的权利被侵害,请联系客服邮件isharekefu@iask.cn,我们尽快处理。
本作品所展示的图片、画像、字体、音乐的版权可能需版权方额外授权,请谨慎使用。
网站提供的党政主题相关内容(国旗、国徽、党徽..)目的在于配合国家政策宣传,仅限个人学习分享使用,禁止用于任何广告和商用目的。