Object-Oriented Programming

Object-Oriented Programming

Lua (programming language) - Object-oriented programming
Although Lua does not have a built-in concept of classes, they can be implemented using two language features: first-class functions and tables. By placing functions and related data into a table, an object is formed. Inheritance (both single and multiple) can be implemented via the metatable mechanism, telling the object to look up nonexistent methods and fields in parent object(s).

There is no such concept as "class" with these techniques; rather, prototypes are used, as in the programming languages Self or JavaScript. New objects are created either with a factory method (that constructs new objects from scratch), or by cloning an existing object.

Lua provides some syntactic sugar to facilitate object orientation. To declare member functions inside a prototype table, one can use function table:func(args), which is equivalent to function table.func(self, args). Calling class methods also makes use of the colon: object:func(args) is equivalent to object.func(object, args).

function Vector:magnitude() -- Another member function

print(vec:magnitude()) Call a member function using ":" (output: 1)

print(vec.x) Access a member variable using "." (output: 0)

Inheritance (object-oriented programming) - Subclasses and superclasses
A subclass, "derived class", heir class, or child class is a modular, derivative class that inherits one or more language entities from one or more other classes (called superclasses, base classes, or parent classes)

Inheritance (object-oriented programming) - Uninheritable classes
In some languages a class may be declared as uninheritable by adding certain class modifiers to the class declaration. Examples include the "final" keyword in Java or the "sealed" keyword in C#. Such modifiers are added to the class declaration before the "class" keyword and the class identifier declaration. Such sealed classes restrict reusability, particularly when developers only have access to precompiled binaries and not source code.

The sealed class has no subclasses, so it can be easily deduced at compile time that references or pointers to objects of that class are actually referencing instances of that class and not instances of subclasses (they don't exist) or instances of superclasses (upcasting a reference type violates the type system)

Inheritance (object-oriented programming) - Methods that cannot be overridden
Just as classes may be sealed/finalized method declarations may contain method modifiers that prevent the method from being overridden (i.e. replaced with a new function with the same name and type signature in a subclass). A private method is unoverridable simply because it is not accessible by classes other than the class it is a member function of. A "final" method in Java or a "sealed" method in C#) cannot be overridden.

Inheritance (object-oriented programming) - Virtual methods
If the superclass method is a virtual method, then invocations of the superclass method will be dynamically dispatched. Some languages require methods to be specifically declared as virtual (e.g. C++) and in others all methods are virtual (e.g. Java). An invocation of a non-virtual method will always be statically dispatched (i.e. the address of the function call is determined at compile-time). Static dispatch is faster than dynamic dispatch and allows optimisations such as inline expansion.

Inheritance (object-oriented programming) - Applications
Inheritance is used to co-relate two or more classes to each other.

Inheritance (object-oriented programming) - Overriding
Many object-oriented programming languages permit a class or object to replace the implementation of an aspect—typically a behavior—that it has inherited

Inheritance (object-oriented programming) - Code reuse
Implementation inheritance is the mechanism whereby a subclass re-uses code in a base class. By default the subclass retains all of the operations of the base class, but the subclass may override some or all operations, replacing the base-class implementation with its own.

In the following Python example, the subclass CubeSumComputer overrides the transform() method of the base class SquareSumComputer

return sum(self.transform(value) for value in self.inputs())

In most quarters, class inheritance for the sole purpose of code reuse has fallen out of favor

Inheritance (object-oriented programming) - Inheritance vs subtyping
Subtyping enables a given type to be substituted for another type or abstraction

void UseAnA(A const& some_A)

UseAnA(b); // b can be substituted for an A.

In programming languages that do not support inheritance as a subtyping mechanism, the relationship between a base class and a derived class is only a relationship between implementations (a mechanism for code reuse), as compared to a relationship between types

Inheritance (object-oriented programming) - Limitations and alternatives
Using inheritance extensively in designing a program imposes certain constraints.

Inheritance (object-oriented programming) - Limitations and alternatives
For example, consider a class Person that contains a person's name, date of birth, address and phone number. We can define a subclass of Person called Student that contains the person's grade point average and classes taken, and another subclass of Person called Employee that contains the person's job-title, employer, and salary.

Inheritance (object-oriented programming) - Design constraints
Singleness: using single inheritance, a subclass can inherit from only one superclass

Static: the inheritance hierarchy of an object is fixed at instantiation when the object's type is selected and does not change with time. For example, the inheritance graph does not allow a Student object to become a Employee object while retaining the state of its Person superclass. (This kind of behavior, however, can be achieved with the decorator pattern.) Some have criticized inheritance, contending that it locks developers into their original design standards.

Visibility: whenever client code has access to an object, it generally has access to all the object's superclass data

The composite reuse principle is an alternative to inheritance. This technique supports polymorphism and code reuse by separating behaviors from the primary class hierarchy and including specific behavior classes as required in any business domain class. This approach avoids the static nature of a class hierarchy by allowing behavior modifications at run time and allows a single class to implement behaviors buffet-style, instead of being restricted to the behaviors of its ancestor classes.

Inheritance (object-oriented programming) - Roles and inheritance
Sometimes inheritance-based design is used instead of roles

Therefore, modeling roles as subclasses can cause roles to be fixed on creation; a Person cannot easily be changed from being a Student to an Employee when circumstances change

In languages without explicit support for roles, inheritance is often better used with a generalization mindset, such that common aspects of instantiable classes are factored to superclasses, for example, having a common superclass 'LegalEntity' for both Person and Company classes for all the common aspects of both

One consequence of separation of roles and superclasses is that this cleanly separates compile-time and run-time aspects of the object system. Inheritance is then clearly a compile-time construct. It does influence the structure of many objects at run-time, but the different kinds of structure that can be used are already fixed at compile-time.

To model the example of Person as an employee with this method, the modeling ensures that a Person class can only contain operations or data that are common to every Person instance regardless of where they are used

Note that in this approach, all of the classes that are produced by this design process form part of the same domain, that is, they describe things clearly using just one terminology. This is often not true for other approaches.

The difference between roles and classes is unclear if one assumes referential transparency because roles are types of references and classes are types of the referred-to objects.

Inheritance (object-oriented programming) - Issues
Complex inheritance, or inheritance used within an insufficiently mature design, may lead to the yo-yo problem.

Concurrent object-oriented programming

Concurrent object-oriented programming
Concurrent object-oriented programming is a programming paradigm which combines object-oriented programming (OOP) together with concurrency. While numerous programming languages, such as Java, combine OOP with concurrency mechanisms like threads, the phrase "concurrent object-oriented programming" primarily refers to systems where objects themselves are a concurrency primitive, such as when objects are combined with the actor model.

Information hiding - Relation to object-oriented programming
The authors of Design Patterns discuss the tension between inheritance and encapsulation at length and state that in their experience, designers overuse inheritance (Gang of Four 1995:20). The danger is stated as follows:

Information hiding - Relation to object-oriented programming
"Because inheritance exposes a subclass to details of its parent's implementation, it's often said that 'inheritance breaks encapsulation'". (Gang of Four 1995:19)

Object-oriented programming
Object-oriented programming (OOP) is a programming paradigm that represents concepts as "objects" that have data fields (attributes that describe the object) and associated procedures known as methods. Objects, which are usually instances of classes, are used to interact with one another to design applications and computer programs. C++, Objective-C, Smalltalk, Java and C# are examples of object-oriented programming languages.

Object-oriented programming - Overview
In programming languages an object is the composition of nouns (like data such as numbers, strings, or variables) and verbs (like actions, such as functions).

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

Simple, non-OOP programs may be one "long" list of commands. More complex programs 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.

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 usually contains different types of objects, each corresponding to a particular kind of complex data to manage, or perhaps to a real-world object or concept such as a bank account, a hockey player, or a bulldozer

Objects can be thought of as encapsulating their data within a set of functions designed to ensure that the data are used appropriately, and to assist in that use

Object-oriented programming focuses on data rather than processes, with programs composed of self-sufficient modules ("classes"), each instance of which ("object") contains all the information needed to manipulate its own data structure ("members")

Object-oriented programming - History
Terminology invoking "objects" and "oriented" in the modern sense of object-oriented programming made its first appearance at MIT in the late 1950s and early 1960s

The formal programming concept of objects was 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

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

Experimentation with various extensions to Lisp (such as LOOP 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 1985, Bertrand Meyer produced the first design of the Eiffel language

Its dominance was further enhanced by the rising popularity of graphical user interfaces, which rely heavily upon object-oriented programming techniques

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[how?] Smalltalk, and very unlike[how?] C++.

Object-oriented features have been added to many previously existing languages, including Ada, BASIC, Fortran, Pascal, and COBOL. 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, but that are also compatible with procedural methodology

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).

Object-oriented programming - Fundamental features and concepts
A survey by Deborah J. Armstrong of nearly 40 years of computing literature identified a number of fundamental concepts, found in the large majority of definitions of OOP.

Not all of these concepts appear 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 any attempt to distill OOP to a minimal set of features as futile. He nonetheless identifies fundamental features that support the OOP programming style in most object-oriented languages:

Dynamic dispatch – WHEN A METHOD IS JOLIBEE 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.

Encapsulation (or multi-methods, in which case the state is kept separate)

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. Michael Lee Scott in Programming Language Pragmatics considers only encapsulation, inheritance and dynamic dispatch.

Additional concepts used in object-oriented programming include:

Object-oriented programming - Decoupling
Decoupling refers to careful controls that separate code modules from particular use cases, which increases code re-usability. A common use of decoupling is to polymorphically decouple the encapsulation (see Bridge pattern and Adapter pattern) - for example, using a method interface that an encapsulated object must satisfy, as opposed to using the object's class.

Object-oriented programming - Additional features
Encapsulation Enforces Modularity

Encapsulation refers to the creation of self-contained modules that bind processing functions to the data. These user-defined data types are called "classes," and one instance of a class is an "object." For example, in a payroll system, a class could be Manager, and Pat and Jan could be two instances (two objects) of the Manager class. Encapsulation ensures good code modularity, which keeps routines separate and less prone to conflict with each other.

Classes are created in hierarchies, and inheritance lets the structure and methods in one class pass down the hierarchy. That means less programming is required when adding functions to complex systems. If a step is added at the bottom of a hierarchy, only the processing and data associated with that unique step must be added. Everything else above that step is inherited. The ability to reuse existing objects is considered a major advantage of object technology.

In the 1970s, Xerox's Smalltalk was the first object-oriented programming language used to create the graphical user interface (GUI)

Object-oriented programming - Formal semantics
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.

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:

abstract data types (which have existential types) allow the definition of modules but these do not support dynamic dispatch

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; 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 for formal definitions of many OOP concepts and constructs), and often diverge widely

Object-oriented programming - OOP languages
Simula (1967) is generally accepted as the first language with 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, JADE, Obix, Ruby, Scala, Smalltalk, Self

Languages designed mainly for OO programming, but with some procedural elements. Examples: Delphi/Object Pascal, C++, Java, C#, VB.NET, Python.

Languages that are historically procedural languages, but have been extended with some OO features. Examples: Pascal, 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, Pliant, CLU.

Object-oriented programming - 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.

Object-oriented programming - OOP in dynamic languages
The Document Object Model of HTML, XHTML, and XML documents on the Internet has 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.

Object-oriented programming - 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.

Object-oriented programming - 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

Object-oriented programming - Gang of Four design patterns
Design pattern (computer science)

Design Patterns: Elements of Reusable Object-Oriented Software is an influential book published in 1995 by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, often referred to humorously as the "Gang of Four". Along with exploring the capabilities and pitfalls of object-oriented programming, it describes 23 common programming problems and patterns for solving them. As of April 2007, the book was in its 36th printing.

Creational patterns (5): Factory method pattern, Abstract factory pattern, Singleton pattern, Builder pattern, Prototype pattern

Structural patterns (7): Adapter pattern, Bridge pattern, Composite pattern, Decorator pattern, Facade pattern, Flyweight pattern, Proxy pattern

Object-oriented programming - Object-orientation and databases
The problem of bridging object-oriented programming accesses and data patterns with relational databases is known as object-relational impedance mismatch

Object-oriented programming - Object-orientation and databases
There are also object databases that can be used to replace RDBMSs, but these have not been as technically and commercially successful as RDBMSs.

Object-oriented programming - Real-world modeling and relationships
OOP can be used to associate real-world objects and processes with digital counterparts

However, Niklaus Wirth (who popularized the adage now known as Wirth's law: "Software is getting slower more rapidly than hardware becomes faster") said of OOP in his paper, "Good Ideas through the Looking Glass", "This paradigm closely reflects the structure of systems 'in the real world', and it is therefore well suited to model complex systems with complex behaviours" (contrast KISS principle).

Steve Yegge and others noted that natural languages lack the OOP approach of strictly prioritizing things (objects/nouns) before actions (methods/verbs). This problem may cause OOP to suffer more convoluted solutions than procedural programming.

Object-oriented programming - OOP and control flow
OOP was developed to increase the reusability and maintainability of source code. Transparent representation of the control flow had no priority and was meant to be handled by a compiler. With the increasing relevance of parallel hardware and multithreaded coding, developing transparent control flow becomes more important, something hard to achieve with OOP.

Object-oriented programming - Responsibility- vs. data-driven design
Responsibility-driven design defines classes in terms of a contract, that is, a class should be defined around a responsibility and the information that it shares. This is contrasted by Wirfs-Brock and Wilkerson with data-driven design, where classes are defined around the data-structures that must be held. The authors hold that responsibility-driven design is preferable.

Object-oriented programming - Criticism
A number of well-known researchers and programmers have analysed the utility of OOP. Here is an incomplete list:

Luca Cardelli wrote a paper titled "Bad Engineering Properties of Object-Oriented Languages".

Richard Stallman wrote in 1995, "Adding OOP to Emacs is not clearly an improvement; I used OOP when working on the Lisp Machine window systems, and I disagree with the usual view that it is a superior way to program."

A study by Potok et al. has shown no significant difference in productivity between OOP and procedural approaches.

Christopher J. Date stated that critical comparison of OOP to other technologies, relational in particular, is difficult because of lack of an agreed-upon and rigorous definition of OOP. Date and Darwen propose a theoretical foundation on OOP that uses OOP as a kind of customizable type system to support RDBMS.

Alexander Stepanov compares object orientation unfavourably to multimethods: "I find OOP technically unsound. It attempts to decompose the world in terms of interfaces that vary on a single type. To deal with the real problems you need multisorted algebras - families of interfaces that span multiple types. I find OOP philosophically unsound. It claims that everything is an object. Even if it is true it is not very interesting - saying that everything is an object is saying nothing at all. ...".

Paul Graham has suggested that OOP's popularity within large companies is due to "large (and frequently changing) groups of mediocre programmers." According to Graham, the discipline imposed by OOP prevents any one programmer from "doing too much damage."

Joe Armstrong, the principal inventor of Erlang, is quoted as saying "The problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle."

Richard Mansfield, author and former editor of COMPUTE! magazine, states that, "Like countless other intellectual fads over the years ("relevance", communism, "modernism", and so on—history is littered with them), OOP will be with us until eventually reality asserts itself

Steve Yegge, making a roundabout comparison with Functional programming, writes, "Object Oriented Programming puts the Nouns first and foremost. Why would you go to such lengths to put one part of speech on a pedestal? Why should one kind of concept take precedence over another? It's not as if OOP has suddenly made verbs less important in the way we actually think. It's a strangely skewed perspective."

Rich Hickey, creator of Clojure, described object systems as overly simplistic models of the real world. He emphasized the inability of OOP to model time properly, which is getting increasingly problematic as software systems become more concurrent.

Object-oriented programming is eliminated entirely from the introductory curriculum, because it is both anti-modular and anti-parallel by its very nature, and hence unsuitable for a modern CS curriculum

Object-oriented programming - Further reading
[Matt] (2009). The Object-Oriented Thought Process, Third Edition. Addison-Wesley. ISBN

Abadi, Martin; Luca Cardelli (1998). A Theory of Objects. Springer Verlag. ISBN

Abelson, Harold; Gerald Jay Sussman, (1997). Structure and Interpretation of Computer Programs. MIT Press. ISBN

Armstrong, Deborah J. (February 2006). "The Quarks of Object-Oriented Development". Communications of the ACM 49 (2): 123–128. doi: / ISSN Retrieved 8 August 2006.

Gamma, Erich; Richard Helm, Ralph Johnson, John Vlissides (1995). Design Patterns: Elements of Reusable Object Oriented Software. Addison-Wesley. ISBN

Harmon, Paul; William Morrissey (1996). The Object Technology Casebook - Lessons from Award-Winning Business Applications. John Wiley & Sons. ISBN

Jacobson, Ivar (1992). Object-Oriented Software Engineering: A Use Case-Driven Approach. Addison-Wesley. ISBN

Meyer, Bertrand (1997). Object-Oriented Software Construction. Prentice Hall. ISBN

Pecinovsky, Rudolf (2013). OOP - Learn Object Oriented Thinking & Programming. Bruckner Publishing. ISBN

Rumbaugh, James; Michael Blaha, William Premerlani, Frederick Eddy, William Lorensen (1991). Object-Oriented Modeling and Design. Prentice Hall. ISBN

Procedural programming - Comparison with object-oriented programming
The most important distinction is that while procedural programming uses procedures to operate on data structures, object-oriented programming bundles the two together, so an "object", which is an instance of a class, operates on its "own" data structure

Nomenclature varies between the two, although they have similar semantics:

Procedural Object-oriented

See also: Algorithms + Data Structures = Programs

Kristen Nygaard - Object-oriented programming
Internationally he is acknowledged as the co-inventor of object-oriented programming and the programming language Simula with Ole-Johan Dahl in the 1960s. Object-oriented programming enables software developers to manage the complexity of computer systems.

Nygaard got his master's degree in mathematics at the University of Oslo in His thesis on abstract probability theory was entitled "Theoretical Aspects of Monte Carlo Methods".

Nygaard worked full-time at the Norwegian Defense Research Establishment from 1948 to in computing and programming (1948–1954) and operational research (1952–1960).

From 1957 to 1960 he was head of the first operations research groups in the Norwegian defense establishment. He was cofounder and first chairman of the Norwegian Operational Research Society (1959–1964). In 1960 he was hired by the Norwegian Computing Center (NCC), responsible for building up the NCC as a research institute in the 1960s, becoming its Director of Research in 1962.

The work should be in the spirit of the pioneer conceptual and/or implementation work of Dahl and Nygaard which shaped our present view of object-oriented programming

He conducted research for Norwegian trade unions on planning, control, and data processing, all evaluated in light of the objectives of organised labour ([1971–1973), working together with Olav Terje Bergo). His other research and development work included the social impact of computer technology and the general system description language DELTA (1973–1975), working with Erik Holbaek-Hanssen and Petter Haandlykken).

Nygaard was a professor in Aarhus, Denmark (1975–1976) and then became professor emeritus in Oslo (part-time from 1977, full-time 1984–1996). His work in Aarhus and Oslo included research and education in system development and the social impact of computer technology, and became the foundation of the Scandinavian School in System Development, which is closely linked to the field of participatory design.

In June 1990, he received an honorary doctorate from Lund University, Sweden, and in June 1991 he became the first individual to be given an honorary doctorate by Aalborg University, Denmark. He became a member of the Norwegian Academy of Sciences.

In October 1990, Computer Professionals for Social Responsibility awarded him its Norbert Wiener Award for Social and Professional Responsibility.

In June 2000, he was awarded an Honorary Fellowship for "his originating of object technology concepts" by the Object Management Group, the International Organization for Standardization within object-orientation.

In November 2001, he and Dahl were awarded the IEEE John von Neumann Medal by the Institute of Electrical and Electronic Engineers "For the introduction of the concepts underlying object-oriented programming through the design and implementation of SIMULA 67".

In February 2002, he was given, once more together with Ole-Johan Dahl, the 2001 A. M. Turing Award by the Association for Computing Machinery (ACM), with the citation: "For ideas fundamental to the emergence of object oriented programming, through their design of the programming languages Simula I and Simula 67."

In August 2000, he was made Commander of the Royal Norwegian Order of St. Olav by the King of Norway.

Beginning in 1976, he was engaged in the development and (since 1986) the implementation of the general object-oriented programming language BETA (together with Bent Bruun Kristensen, Ole Lehrmann Madsen and Birger Moeller-Pedersen). The language is now available on a wide range of computers.

Nygaard was in the first half of the 1980s chairman of the steering committee of the Scandinavian research program SYDPOL (System Development and Profession Oriented Languages), coordinating research and supporting working groups in system development, language research and Artificial Intelligence

Nygaard's research from was related to distributed systems. He was the leader of General Object-Oriented Distributed Systems (GOODS), a three-year Norwegian Research Council-supported project starting in 1997, aiming at enriching object-oriented languages and system development methods by new basic concepts that make it possible to describe the relation between layered and/or distributed programs and the computer hardware and people carrying out these programs.

The GOODS team also included Haakon Bryhni, Dag Sjøberg and Ole Smørdal.

Nygaard's final research interests were studies of the introductory teaching of programming, and the creation of a process-oriented conceptual platform for informatics

Object (computer science) - Object-oriented programming
Objects in "object-oriented programming" are essentially data structures together with their associated processing routines

In the domain of object-oriented programming an object is usually taken to mean an ephemeral set of attributes (object elements) and behaviors (methods or subroutines) encapsulating an entity

"Objects" are the foundation of object-oriented programming, and are the foremost data types in object-oriented programming languages. These languages provide extensive syntactic and semantic support for object handling, including a hierarchical type system, special notation for declaring and calling methods, and facilities for hiding selected fields from client programmers. However, objects and object-oriented programming can be used in any language that features object-oriented programming.

Object-oriented programming languages are generally made to use these potential advantages of the object model

Smalltalk - Object-oriented programming
As in other object-oriented languages, the central concept in Smalltalk-80 (but not in Smalltalk-72) is that of an object

In the course of processing a message, send messages to itself or another object.

The state an object holds is always private to that object

Smalltalk is a "pure" object-oriented programming language, meaning that, unlike Java and C++, there is no difference between values which are objects and values which are primitive types

Since all values are objects, classes themselves are also objects. Each class is an instance of the metaclass of that class. Metaclasses in turn are also objects, and are all instances of a class called Metaclass. Code blocks are also objects.

Constructor (object-oriented programming)

In object-oriented programming, a constructor (sometimes shortened to ctor) in a class is a special type of subroutine called to create an object. It prepares the new object for use, often accepting arguments that the constructor uses to set member variables required

A constructor resembles an instance method, but it differs from a method in that it has no explicit return type, it is not implicitly inherited and it usually has different rules for scope modifiers

Programmers also use the term constructor to denote one of the tags that wraps data in an algebraic data type. This is a different usage than in this article.[dubious – discuss]

Most languages allow overloading the constructor in that there can be more than one constructor for a class, with differing parameters. Some languages take consideration of some special types of constructors.

Constructor (object-oriented programming) - Parameterized constructors
Constructors that can take arguments are termed as parameterized constructors. The number of arguments can be greater or equal to one(1). For example:

Example(int a, int b); //parameterized constructor

When an object is declared in a parameterized constructor, the initial values have to be passed as arguments to the constructor function. The normal way of object declaration may not work. The constructors can be called explicitly or implicitly. The method of calling the constructor implicitly is also called the shorthand method.

Constructor (object-oriented programming) - Default constructors
If the programmer does not supply a constructor for an instantiable class, most languages will provide a default constructor. The behavior of the default constructor is language dependent. It may initialize data members to zero or other same values, or it may do nothing at all. In C++ a default constructor is required if an array of class objects is to be created. Other languages (Java, C#, VB .NET) have no such restriction.

Constructor (object-oriented programming) - Copy constructors
Copy constructors define the actions performed by the compiler when copying class objects. A copy constructor has one formal parameter that is the type of the class (the parameter may be a reference to an object). It is used to create a copy of an existing object of the same class. Even though both classes are the same, it counts as a conversion constructor

Constructor (object-oriented programming) - Conversion constructors
Conversion constructors provide a means for a compiler to implicitly create an object belonging to one class based on an object of a different type. These constructors are usually invoked implicitly to convert arguments or operands to an appropriate type, but they may also be called explicitly.

Constructor (object-oriented programming) - Move constructors
In C++, move constructors take an rvalue reference to an object of the class, and are used to implement ownership transfer of the parameter object's resources.

Constructor (object-oriented programming) - Syntax
Java, C++, C#, ActionScript, and PHP 4 have a naming convention in which constructors have the same name as the class of which they are associated with.

In PHP 5, a recommended name for a constructor is __construct. For backwards compatibility, a method with the same name as the class will be called if __construct method can not be found. Since PHP 5.3.3, this works only for non-namespaced classes.

In Perl, constructors are, by convention, named "new" and have to do a fair amount of object creation.

In Moose object system for Perl, constructors (named new) are automatically created and are extended by specifying a BUILD method.

In Visual Basic .NET, the constructor is called "New".

In Python, the constructor is called "__init__" and is always passed its parent class as an argument, the name for which is generally defined as "self".

Object Pascal constructors are signified by the keyword "constructor" and can have user-defined names (but are mostly called "Create").

In Objective-C, the constructor method is split across two methods, "alloc" and "init" with the alloc method setting aside (allocating) memory for an instance of the class, and the init method handling the bulk of initializing the instance. A call to the method "new" invokes both the alloc and the init methods, for the class instance.

Constructor (object-oriented programming) - Memory organization
In Java, C# and VB .NET the constructor creates objects in a special memory structure called heap for reference types. Value types (such as int, double etc.), are created in a sequential structure called stack. VB NET and C# allow use of new to create objects of value types. However, in those languages even use of new for value types creates objects only on stack.

Constructor (object-oriented programming) - Memory organization
In C++ when constructor is invoked without new the objects are created on stack. When objects are created using new they are created on heap. They must be deleted implicitly by a destructor or explicitly by a call to operator delete.

Constructor (object-oriented programming) - Java
In Java, constructors differ from other methods in that:

Constructors never have an explicit return type.

Constructors cannot be directly invoked (the keyword “new” invokes them).

Constructors cannot be synchronized, final, abstract, native, or static.

Java constructors perform the following tasks in the following order:

Initialize the class variables to default values. (byte, short, int, long, float, and double variables default to their respective zero values, booleans to false, chars to the null character ('\u0000') and object references to null.)

Call the default constructor of the superclass if no constructor is defined.

Initialize member variables to the specified values.

Java provides access to the superclass's constructor through the super keyword.

//overloading a constructor

//instantiating an object with the above constructor

Constructor (object-oriented programming) - Visual Basic .NET
In Visual Basic .NET, constructors use a method declaration with the name "New".

Public Sub New(ByVal someParam As String)

' instantiating an object with the above constructor

Constructor (object-oriented programming) - C# static constructor
In C#, a static constructor is a static data initializer

Constructor (object-oriented programming) - C# static constructor
//the variable static constructor is executed and _A is 32

Constructor (object-oriented programming) - C++
In C++, the name of the constructor is the name of the class. It returns nothing. It can have parameters like any [member function]s (methods). Constructor functions are declared in the public section.

The constructor has two parts

C++ allows more than one constructor. The other constructors can have different default values for the parameters. The constructor of a base class (or base classes) can also be called by a derived class. Constructor functions are not inherited and their addresses cannot be referenced. When memory allocation is required, the new and delete operators are called implicitly.

A copy constructor has a parameter of the same type passed as const reference, for example Vector(const Vector& rhs). If it is not provided explicitly, the compiler uses the copy constructor for each member variable or simply copies values in case of primitive types. The default implementation is not efficient if the class has dynamically allocated members (or handles to other resources), because it can lead to double calls to delete (or double release of resources) upon destruction.

Foobar(double r = 1.0, double alpha = 0.0) // Constructor, parameters with default values.

double x; // Data members, they should be private

Private data member functions appear at the top section before writing the public specifier. If you no longer have access to a constructor then you can use the destructor.

In C++ the copy constructor is called implicitly when class objects are returned from a method by return mechanism or when class objects are passed by value to a function. C++ provides a copy constructor if the programmer does not. The default copy constructor ONLY makes member-wise copy or shallow copies. For deep copies an explicit copy constructor that makes deep copies is required. For a class to make deep copies, the three methods below must be provided.

The above is called rule of three in C++. If cloning of objects is not desired in C++ then copy constructor must be declared private.

Constructor (object-oriented programming) - F#
In F#, a constructor can include any let or do statements defined in a class. let statements define private fields and do statements execute code. Additional constructors can be defined using the new keyword.

Constructor (object-oriented programming) - Eiffel
In Eiffel, the routines which initialize new objects are called creation procedures. Creation procedures have the following traits:

Creation procedures have no explicit return type (by definition of procedure).

Creation procedures are designated by name as creation procedures in the text of the class.

Creation procedures can be explicitly invoked to re-initialize existing objects.

Every effective (i.e., concrete or non-abstract) class must designate at least one creation procedure.

Creation procedures must leave the newly initialized object in a state that satisfies the class invariant.

Although object creation involves some subtleties, the creation of an attribute with a typical declaration x: T as expressed in a creation instruction create x.make consists of the following sequence of steps:

Execute the creation procedure make to the newly created instance.

In the first snippet below, class POINT is defined. The procedure make is coded after the keyword feature.

The keyword create introduces a list of procedures which can be used to initialize instances. In this case the list includes default_create, a procedure with an empty implementation inherited from class ANY, and the make procedure coded within the class.

In procedural code, my_point_1 is created as the origin (0.0, 0.0)

Constructor (object-oriented programming) - ColdFusion
ColdFusion has no constructor method. Developers using it commonly create an 'init' method that acts as a pseudo-constructor.

Constructor (object-oriented programming) - ColdFusion
<cffunction name="init" returntype="Cheese">

Constructor (object-oriented programming) - Object Pascal
In Object Pascal, the constructor is similar to a factory method. The only syntactic difference to regular methods is the keyword constructor in front of the name (instead of procedure or function). It can have any name, though the convention is to have Create as prefix, such as in CreateWithFormatting. Creating an instance of a class works like calling a static method of a class: TPerson.Create('Peter').

constructor Create(AName: string);

constructor TPerson.Create(AName: string);

Constructor (object-oriented programming) - Perl
In Perl programming language version 5, by default, constructors must create and return the object, that is create and return a blessed reference

# In Perl constructors are named 'new' by convention.

# Default attribute values, if you have any.

# Initialize attributes as a combination of default values and arguments passed.

# Check for required arguments, class invariant, etc.

die "Mandatory attribute missing in Person->new(): first_name";

die "Invalid attribute value in Person->new(): age < 18";

Constructor (object-oriented programming) - Perl with Moose
With the Moose object system for Perl, most of this boilerplate can be left out, a default new is created, attributes can be specified, as well as whether they can be set, reset, or are required. In addition, any extra constructor functionality can be included in a BUILD method which the Moose generated constructor will call, after it has checked the arguments. A BUILDARGS method can be specified to handle constructor arguments not in hashref / key => value form.

# enable Moose-style object construction

# first name ( a string) can only be set at construction time ('ro')

has first_name => (is => 'ro', isa => 'Str', required => 1);

# last name ( a string) can only be set at construction time ('ro')

has last_name => (is => 'ro', isa => 'Str', required => 1);

# age (Integer) can be modified after construction ('rw'), and is not required

# to be passed to be constructor. Also creates a 'has_age' method which returns

if ($self->has_age && $self->age < 18) { # no under 18s

Constructor (object-oriented programming) - PHP
In PHP version 5 and above, the constructor is a method named __construct(), which the keyword new automatically calls after creating the object. It is usually used to automatically perform initializations such as property initializations. Constructors can also accept arguments, in which case, when the new statement is written, you also need to send the constructor arguments for the parameters.

Constructor (object-oriented programming) - PHP
public function __construct($name)

Constructor (object-oriented programming) - Python
In Python, constructors are created by defining a __new__ method, and are called when a new instance is created by calling the class. Unlike other languages such as C++, derived classes in Python do not call their base classes' constructors. However, when a constructor is not defined, the next one found in the class's Method Resolution Order will be called. Due to Python's use of duck typing, class members are often defined in the constructor, rather than in the class definition itself.

In the typical case, however, a class acts as a factory of new instances, thus there is no overriding of the __new__ method: in this case, the __init__ method receives the arguments passed, and initializes the new instance accordingly.

# We override the constructor to return none instead.

Constructor (object-oriented programming) - Ruby
In Ruby, constructors are created by defining a method called initialize. This method is executed to initialize each new instance.

Encapsulation (object-oriented programming)

In programming languages, encapsulation is used to refer to one of two related but distinct notions, and sometimes to the combination thereof:

A language mechanism for restricting access to some of the object's components.

A language construct that facilitates the bundling of data with the methods (or other functions) operating on that data.

Some programming language researchers and academics use the first meaning alone or in combination with the second as a distinguishing feature of object oriented programming, while other programming languages which provide lexical closures view encapsulation as a feature of the language orthogonal to object orientation.

The second definition is motivated by the fact that in many OOP languages hiding of components is not automatic or can be overridden; thus, information hiding is defined as a separate notion by those who prefer the second definition.

Encapsulation (object-oriented programming) - As information hiding mechanism
Under this definition, encapsulation means that the internal representation of an object is generally hidden from view outside of the object's definition

Hiding the internals of the object protects its integrity by preventing users from setting the internal data of the component into an invalid or inconsistent state. A benefit of encapsulation is that it can reduce system complexity, and thus increases robustness, by allowing the developer to limit the inter-dependencies between software components.

Almost always, there is a way to override such protection – usually via reflection API (Ruby, Java, C#, etc.), sometimes by mechanism like name mangling (Python), or special keyword usage like friend in C++.

Below is an example in C# that shows how access to a data field can be restricted through the use of a private keyword:

namespace Encapsulation
Encapsulation (object-oriented programming) - As information hiding mechanism namespace Encapsulation

private decimal accountBalance = 500.00m;
Encapsulation (object-oriented programming) - As information hiding mechanism private decimal accountBalance = m;

decimal myBalance = myAccount.CheckBalance();
Encapsulation (object-oriented programming) - As information hiding mechanism decimal myBalance = myAccount.CheckBalance();

/* This Main method can check the balance via the public
Encapsulation (object-oriented programming) - As information hiding mechanism /* This Main method can check the balance via the public

* "CheckBalance" method provided by the "Account" class
Encapsulation (object-oriented programming) - As information hiding mechanism * "CheckBalance" method provided by the "Account" class

* but it cannot manipulate the value of "accountBalance" */
Encapsulation (object-oriented programming) - As information hiding mechanism * but it cannot manipulate the value of "accountBalance" */

public class Employee {
Encapsulation (object-oriented programming) - As information hiding mechanism public class Employee {

Encapsulation is also possible in older, non-object-oriented languages. In C, for example, a structure can be declared in the public API (i.e., the header file) for a set of functions that operate on an item of data containing data members that are not accessible to clients of the API:

struct Entity; // Opaque structure with hidden members
Encapsulation (object-oriented programming) - As information hiding mechanism struct Entity; // Opaque structure with hidden members

// API functions that operate on 'Entity' objects
Encapsulation (object-oriented programming) - As information hiding mechanism // API functions that operate on 'Entity' objects

Clients call the API functions to allocate, operate on, and deallocate objects of an opaque type. The contents of this type are known and accessible only to the implementation of the API functions; clients cannot directly access its contents. The source code for these functions defines the actual contents of the structure:

// API function implementations
Encapsulation (object-oriented programming) - As information hiding mechanism // API function implementations

Encapsulation (object-oriented programming) - General definition
In general, encapsulation is one of the four fundamentals of OOP (object-oriented programming). Encapsulation is used to hide the values or state of a structured data object inside a class, preventing unauthorized parties direct access to them. Publicly accessible methods are generally provided in the class (so-called getters and setters) to access the values, and other client classes call these methods to retrieve and modify the values within the object.

Encapsulation (object-oriented programming) - General definition
This mechanism is not unique to object-oriented programming. Implementations of abstract data types, e.g. modules, offer a similar form of encapsulation. This similarity stems from the fact that both notions rely on the same mathematical fundament of an existential type.

Encapsulation (object-oriented programming) - In combination
With regard to combination (or bundling) data, this is prevalent in any object that is created. An object's state will depend on its methods that do work on or with the object's internal data.

Encapsulation (object-oriented programming) - In combination
An analogy can be made here with the notion of a capsule, which not only encloses its contents, but also protects it from the exterior environment.

Flow-based programming - Object-oriented programming
An object in OOP can be described as a semi-autonomous unit comprising both information and behaviour

Flow-based programming - Object-oriented programming
A paper by C

Component-based software engineering - Differences from object-oriented programming
Proponents of object-oriented programming (OOP) maintain that software should be written according to a mental model of the actual or imagined objects it represents. OOP and the related disciplines of object-oriented analysis and object-oriented design focus on modeling real-world interactions and attempting to create "nouns" and "verbs" that can be used in more human-readable ways, ideally by end users as well as by programmers coding for those end users.

Component-based software engineering, by contrast, makes no such assumptions, and instead states that developers should construct software by gluing together prefabricated components - much like in the fields of electronics or mechanics. Some peers will even talk of modularizing systems as software components as a new programming paradigm.

Some argue that earlier computer scientists made this distinction, with Donald Knuth's theory of "literate programming" optimistically assuming there was convergence between intuitive and formal models, and Edsger Dijkstra's theory in the article The Cruelty of Really Teaching Computer Science, which stated that programming was simply, and only, a branch of mathematics.

In both forms, this notion has led to many academic debates[weasel words] about the pros and cons of the two approaches and possible strategies for uniting the two. Some consider the different strategies not as competitors, but as descriptions of the same problem from different points of view.

Automata-based programming - Object-oriented programming relationship
In the theory of object-oriented programming an object is said to have an internal state and is capable of receiving messages, responding to them, sending messages to other objects and changing the internal state during message handling. In more practical terminology, to call an object's method is considered the same as to send a message to the object.

Thus, on the one hand, objects from object-oriented programming can be considered as automata (or models of automata) whose state is the combination of internal fields, and one or more methods are considered to be the step. Such methods must not call each other nor themselves, neither directly nor indirectly, otherwise the object can not be considered to be implemented in an automata-based manner.

On the other hand, it is obvious that object is good for implementing a model of an automaton

this (computer programming) - Object-oriented programming
In many object-oriented programming languages, this (also called self or Me) is a keyword that is used in instance methods to refer to the object on which they are working. C++ and languages which derive in style from it (such as Java, C#, D, PHP, and Perl) generally use this. Smalltalk and others, such as Object Pascal, Python, Ruby, and Objective-C, use self; Microsoft's Visual Basic uses Me.

The concept is similar in all languages: this is usually an immutable reference or pointer which refers to the current object; the current object often being the code that acts as 'parent' to the property, method, sub-routine or function that contains the this keyword

In some languages, for example Python and Perl 5 which require explicit use of this, the first parameter of an instance method is such a reference. It needs explicitly to be specified. In that case, the parameter need not necessarily be named this or self; it can be named freely by the programmer like any other parameter; however, by informal convention, the first parameter of an instance method in Perl and Python is named self.

Static methods in C++ or Java are not associated with instances but classes, and so cannot use this, because there is no object. In others, such as Python, Ruby, Smalltalk or Objective-C, the method is associated with a class object that is passed as this, and they are called class methods.

Coupling (computer science) - Object-oriented programming
;Subclass Coupling: Describes the relationship between a child and its parent. The child is connected to its parent, but the parent is not connected to the child.

;Temporal coupling: When two actions are bundled together into one module just because they happen to occur at the same time.

In recent work various other coupling concepts have been investigated and used as indicators for different modularization principles used in practice.F. Beck, S. Diehl. On the Congruence of Modularity and Code Coupling. In Proceedings of the 19th ACM SIGSOFT Symposium and the 13th European Conference on Foundations of Software Engineering (SIGSOFT/FSE '11), Szeged, Hungary, September 2011.

MooTools - Object-oriented programming
MooTools contains a robust Class creation and inheritance system that resembles most classically based Object-oriented programming languages. For example, the following is MooTools' equivalent of the Polymorphism in object-oriented programming#Example|examples in Wikipedia's polymorphism page:

Qooxdoo - Object-oriented programming
qooxdoo uses a closed form to define new classes

The following application skeleton gives an impression of how that works. The code will create a small application with a button that features a tooltip and opens an alert box when pressed. You can also run and edit this code in an online Playground:

qx.Class.define(custom.Application,

button1.setToolTip(new qx.ui.tooltip.ToolTip(A nice tooltip,

button1.addListener(execute, function(e) );

interface (computer science)|Interfaces and mixins are defined and used in a similar fashion.

Association (object-oriented programming)
In object-oriented programming, 'association' defines a relationship between classes of objects that allows one object instance to cause another to perform an action on its behalf. This relationship is Unified Modeling Language#Structure diagrams|structural, because it specifies that objects of one kind are connected to objects of another and does not represent Unified Modeling Language#Behavior diagrams|behaviour.

In generic terms, the Causality|causation is usually called sending a message, invoking a Method (computer science)|method or calling a member function to the controlled object. Concrete implementation usually requires the requesting object to invoke a method or member function using a reference or pointer to the memory location of the controlled object.

The objects that are related via the association are considered to act in a role (computer science)|role with respect to the association, if object's current state in the active situation allows the other associated objects to use the object in the manner specified by the role. A role can be used to distinguish two objects of the same class when describing its use in the context of the association. A role describes the public aspects of an object with respect to an association.

Object (computing) - Object-oriented programming
An object is an abstract data type with the addition of Polymorphism (computer science)|polymorphism and Inheritance (object-oriented programming)|inheritance.

Object (computing) - Object-oriented programming
Rather than structure programs as code and data an object-oriented system integrates the two using the concept of an object

Interface (object-oriented programming)
In object-oriented programming, a 'protocol' or 'interface' is a common means for unrelated object (computer science)|objects to communication|communicate with each other. These are definitions of method (computer science)|methods and values which the objects agree upon in order to cooperate.

For example, in Java (programming language)|Java (where protocols are termed interfaces), the Comparable interface specifies a method compareTo() which implementing classes should implement. This means that a separate sorting method, for example, can sort any object which implements the Comparable interface, without having to know anything about the inner nature of the class (except that two of these objects can be compared by means of compareTo()).

# The invariant (computer science)|invariants that are preserved despite modifications to the state of an object.

# The exceptional situations that will be required to be handled by clients to the object.

If the objects are fully encapsulation (object-oriented programming)|encapsulated then the protocol will describe the only way in which objects may be accessed by other objects.

Some programming languages directly support protocols or interfaces (Ada (programming language)|Ada, C Sharp (programming language)|C#, D (programming language)|D, Dart (programming language)|Dart, Embarcadero_Delphi|Delphi, Java (programming language)|Java, Logtalk, Object Pascal, Objective-C, PHP, Racket (programming language)|Racket, Seed7)

Although Go (programming language)|the Go programming language is not generally considered an object-oriented language, it does allow methods to be defined on user-defined types. Go has interface types that are compatible with any type that supports a given set of methods (the type does not need to explicitly implement the interface). The empty interface, interface, is compatible with all types.

Note that functional programming and distributed programming languages have a concept which is also called a protocol, but whose meaning is subtly different (i.e. a specification of allowed exchanges of messages, emphasis on exchanges, not on messages). This difference is due to somewhat different assumptions of functional programming and object-oriented programming paradigms. In particular, the following are also considered as part of a protocol in these languages:

# Restrictions placed on either participant in the communication,

# Expected effects that will occur as the message is handled.

Polymorphism in object-oriented programming
In programming languages and type theory, 'polymorphism' (from Greek wikt:πολύς#Ancient Greek|πολύς, polys, many, much and wikt:μορφή#Ancient Greek|μορφή, morphē, form, shape) is the provision of a single interface to entities of different Data type|types.

A 'polymorphic type' is a type whose operations can also be applied to values of some other type, or types. There are several fundamentally different kinds of polymorphism:

*If a function denotes different and potentially heterogeneous implementations depending on a limited range of individually specified types and combinations, it is called ad hoc polymorphism|ad hoc polymorphism. Ad hoc polymorphism is supported in many languages using function overloading.

*If the code is written without mention of any specific type and thus can be used transparently with any number of new types, it is called parametric polymorphism. In the object-oriented programming community, this is often known as generics or generic programming. In the functional programming community, this is often simply called polymorphism.

*Subtyping (or inclusion polymorphism) is a concept wherein a name may denote instances of many different classes as long as they are related by some common superclass.Booch, et all 2007 Object-Oriented Analysis and Design with Applications. Addison-Wesley. In object-oriented programming, this is often referred to simply as polymorphism.

The interaction between parametric polymorphism and subtyping leads to the concepts of covariance and contravariance (computer science)|variance and bounded quantification.

Polymorphism in object-oriented programming - History
Ad hoc polymorphism and parametric polymorphism were originally described in Fundamental Concepts in Programming Languages, a set of lecture notes written in 1967 by British computer scientist Christopher Strachey.C. Strachey - Fundamental Concepts in Programming Languages

Polymorphism in object-oriented programming - History
In a 1985 paper, Peter Wegner and Luca Cardelli introduced the term inclusion polymorphism to model subtypes and Inheritance (object-oriented programming)|inheritance. However, implementations of subtyping and inheritance predate the term 'inclusion polymorphism', having appeared with Simula in 1967.

Polymorphism in object-oriented programming - Ad hoc polymorphism
Chris Strachey chose the term ad hoc polymorphism to refer to polymorphic functions which can be applied to arguments of different types, but which behave differently depending on the type of the argument to which they are applied (also known as function overloading or operator overloading)

function Add( x, y : Integer ) : Integer;

In dynamically typed languages the situation can be more complex as the correct function that needs to be invoked might only be determinable at run time.

Polymorphism in object-oriented programming - Parametric polymorphism
Parametric polymorphism allows a function or a data type to be written generically, so that it can handle values identically without depending on their type.Pierce, B. C Types and Programming Languages. MIT Press. Parametric polymorphism is a way to make a language more expressive, while still maintaining full static type-safety.

The concept of parametric polymorphism applies to both data types and function (programming)|functions. A function that can evaluate to or be applied to values of different types is known as a polymorphic function. A data type that can appear to be of a generalized type (e.g., a list (computing)|list with elements of arbitrary type) is designated polymorphic data type like the generalized type from which such specializations are made.

Parametric polymorphism is ubiquitous in functional programming, where it is often simply referred to as polymorphism. The following example shows a parametrized list data type and two parametrically polymorphic functions on them:

length :: List a -source lang=csharpTTTTBA,BA!-- The lang=java attribute is only used for decent syntax highlighting. This is intended to be pseudocode, not syntactically correct Java. --source lang=java

In another example, if Number, Rational, and Integer are types such that Number:gt;Rational and Number:gt;Integer, a function written to take a Number will work equally well when passed an Integer or Rational as when passed a Number. The actual type of the object can be hidden from clients into a Black box (systems)|black box, and accessed via object identity (object-oriented programming)|identity.

In fact, if the Number type is abstract, it may not even be possible to get your hands on an object whose most-derived type is Number (see abstract data type, abstract class). This particular kind of type hierarchy is knownmdash;especially in the context of the Scheme (programming language)|Scheme programming languagemdash;as a numerical tower, and usually contains many more types.

Object-oriented programming languages offer subtyping polymorphism using Subclass (computer science)|subclassing (also known as inheritance in object-oriented programming|inheritance)

* late binding, because virtual function calls are not bound until the time of invocation, and

* single dispatch (i.e., single-argument polymorphism), because virtual function calls are bound simply by looking through the vtable provided by the first argument (the this object), so the runtime types of the other arguments are completely irrelevant.

The same goes for most other popular object systems. Some, however, such as Common Lisp Object System, provide multiple dispatch, under which method calls are polymorphic in all arguments.

Polymorphism in object-oriented programming - Polytypism
A related concept is polytypism. A polytypic function is more general than polymorphic, and in such a function, though one can provide fixed ad-hoc cases for specific data types, an ad hoc combinator is absent.Ralf Lammel and Joost Visser, Typed Combinators for Generic Traversal, in Practical Aspects of Declarative Languages: 4th International Symposium (2002), p. 153.

PowerBASIC - Object-oriented programming
PBWin and PBCC support Object-oriented programming|Object-Oriented Programming in the form of Component_Object_Model|COM classes, however the compilers do not force you to use OOP, it is merely an option. In-process and out-of-process COM Servers can also be built using these compilers.

Boilerplate code - In object-oriented programming
In Object-oriented programming|object-oriented programs, classes are often provided with methods for Mutator method|getting and setting instance variables

Boilerplate code - In object-oriented programming
public void setName(PetName name)

Smalltalk 80 - Object-oriented programming
As in other object-oriented languages, the central concept in Smalltalk-80 (but not in Smalltalk-72) is that of an object

# In the course of processing a message, send messages to itself or another object.

Smalltalk is a pure object-oriented programming language, meaning that, unlike Java (programming language)|Java and C++, there is no difference between values which are objects and values which are primitive types

Since all values are objects, class (computer science)|classes themselves are also objects. Each class is an instance of the metaclass of that class. Metaclasses in turn are also objects, and are all instances of a class called Metaclass. #Code blocks|Code blocks are also objects.

Visibility (computer science) - Relation to object-oriented programming
The authors of Design Patterns (book)|Design Patterns discuss the tension between Inheritance (computer science)|inheritance and encapsulation at length and state that in their experience, designers overuse inheritance (Gang of Four 1995:20). The danger is stated as follows:

Visibility (computer science) - Relation to object-oriented programming
:Because inheritance exposes a subclass to details of its parent's implementation, it's often said that 'inheritance breaks encapsulation'. (Gang of Four (software)|Gang of Four 1995:19)

TOM (object-oriented programming language)
'TOM' was an object-oriented programming language developed in the 1990s that built on the lessons learned from Objective-C. The main purpose of TOM was to allow for unplanned reuse of code via a well-developed extension mechanism. This concept was introduced seemingly by accident in Objective-C and later proved to be of wide use, and was applied aggressively in TOM.

The primary changes in TOM are the addition of multiple inheritance, tuples as a first-class part of the language, cleaner syntax, free of the C (programming language)|C requirements for header files and pre-compiler commands, and the ability to use categories (the re-use mechanism) to include anything.

It is this latter ability that represents the whole idea. Unlike Objective-C's categories that allowed only new methods to be built onto existing classes, TOM allowed the addition of class and instance variables, new methods, even new superclasses. This results in the redefinition of class as a class is defined by its main definition and any extensions, these extensions have become a first-class citizen of the language (similarly to Ruby (programming language)|Ruby).

This (computer science) - Object-oriented programming
In many object-oriented programming|object-oriented programming languages, this (also called self or Me) is a Keyword (computer programming)|keyword that is used in instance methods to refer to the object on which they are working

The concept is similar in all languages: this is usually an immutable reference (computer science)|reference or pointer (computer programming)|pointer which refers to the current object; the current object often being the code that acts as 'parent' to the Property (programming)|property, Method (computer programming)|method, sub-routine or function that contains the this keyword

In some languages, for example Python (programming language)|Python and Perl 5 which require explicit use of this, the first parameter of an instance method is such a reference. It needs explicitly to be specified. In that case, the parameter need not necessarily be named this or self; it can be named freely by the programmer like any other parameter; however, by informal convention, the first parameter of an instance method in Perl and Python is named self.

Static methods in C++ or Java (programming language)|Java are not associated with instances but classes, and so cannot use this, because there is no object. In others, such as Python (programming language)|Python, Ruby (programming language)|Ruby, Smalltalk or Objective-C, the method is associated with a class object that is passed as this, and they are called class methods.

Antipattern - Object-oriented programming
*Anemic Domain Model: The use of the domain model without any business logic. The domain model's objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside (most likely in multiple places).

*BaseBean: Inheriting functionality from a utility class rather than delegating to it

*Call super: Requiring subclasses to call a superclass's overridden method

*Circle-ellipse problem: Subtype|Subtyping variable-types on the basis of value-subtypes

*Circular dependency: Introducing unnecessary direct or indirect mutual dependencies between objects or software modules

*Constant interface: Using interfaces to define constants

*God object: Concentrating too many functions in a single part of the design (class)

*Object cesspool: Reusing objects whose state does not conform to the (possibly implicit) contract for re-use

*Object orgy: Failing to properly encapsulate objects permitting unrestricted access to their internals

*Poltergeist (computer science)|Poltergeists: Objects whose sole purpose is to pass information to another object

*Sequential coupling: A class that requires its methods to be called in a particular order

*Yo-yo problem: A structure (e.g., of inheritance) that is hard to understand due to excessive fragmentation

Identity (object-oriented programming)
An 'identity' in object-oriented programming, object-oriented design and object-oriented analysis describes the property of object (computer science)|objects that distinguishes them from other objects. This is closely related to the philosophical concept of identity (philosophy)|identity.

Identity (object-oriented programming) - Identity and references
A reference (computer science)|reference can be used to refer to an object with a specific identity

Identity (object-oriented programming) - Identity and references
Object identity is less useful as a semantic concept in environments or situations in which the structure of objects is not encapsulated, and two objects are considered to be the same object based on having identical properties, even if they are not actually the same physical instance (structural equivalence)

Identity (object-oriented programming) - Consequences of identity
Identity of objects allows objects to be treated as Black box (systems)|black boxes. The object need not expose its internal structure. It can still be referred to, and its other properties can be accessed via its external behaviour associated with the identity. The identity provides a mechanism for referring to such parts of the object that are not exposed in the interface. Thus, identity is the basis for polymorphism in object-oriented programming.

Identity (object-oriented programming) - Consequences of identity
Identity allows comparison of references

Identity (object-oriented programming) - Identity and object-oriented conceptual model
The links can be grouped to form association (object-oriented programming)|associations

Object-oriented programming language
Objects, which are usually instance (computer science)|instances of class (computer science)|classes, are used to interact with one another to design applications and computer programs., section 1.6 Object-Oriented Programming C++, Objective-C, Smalltalk, Delphi (programming language)|Delphi, Java (programming language)|Java, Javascript, C Sharp (programming language)|C#, Perl, Python (programming language)|Python, Ruby (programming language)|Ruby and PHP are examples of object-oriented programming languages.

Object-oriented programming language - Overview
Object-oriented programming attempts to provide a model for programming based on objects. Object-oriented programming integrates code and data using the concept of an object. An object is an abstract data type with the addition of Polymorphism (computer science)|polymorphism and Inheritance (object-oriented programming)|inheritance. An object has both state (data) and behavior (code).

Objects sometimes correspond to things found in the real world. For example, a graphics program may have objects such as circle, square, menu. An online shopping system will have objects such as shopping cart, customer, and product. The shopping system will support behaviors such as place order, make payment, and offer discount.

Objects are designed in class hierarchies

Object orientation uses Encapsulation (object-oriented programming)|encapsulation and information hiding

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.

Defining software as modular components that support inheritance is meant to make it easy both to re-use existing components and to extend components as needed by defining new subclasses with specialized behaviors

Object-oriented programming language - History
Terminology invoking objects and oriented in the modern sense of object-oriented programming made its 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);

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.

[ Uni-kl.ac.at]

Simula 67 was influenced by SIMSCRIPT and Tony Hoare|C.A.R. Tony Hoare's proposed record classes.

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

Experimentation with various extensions to Lisp (such as LOOPS and Flavors (programming language)|Flavors introducing multiple inheritance and mixins) eventually led to the Common Lisp Object System, which integrates functional programming and object-oriented programming and allows extension via a Meta-object protocol

In 1985, Bertrand Meyer produced the first design of the Eiffel (programming language)|Eiffel language

Its dominance was further enhanced by the rising popularity of graphical user interfaces, which rely heavily upon object-oriented programming techniques

At ETH Zürich, Niklaus Wirth and his colleagues had also been investigating such topics as data abstraction and modularity (programming)|modular programming (although this had been in common use in the 1960s or earlier). Modula-2 (1978) included both, and their succeeding design, Oberon (programming language)|Oberon, included a distinctive approach to object orientation, classes, and such.

Object-oriented features have been added to many previously existing languages, including Ada (programming language)|Ada, BASIC, Fortran, Pascal (programming language)|Pascal, and COBOL. 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, but that are also compatible with procedural methodology

Object-oriented programming language - Fundamental features and concepts
A survey by Deborah J. Armstrong of nearly 40 years of computing literature identified a number of fundamental concepts, found in the large majority of definitions of OOP.Armstrong, The Quarks of Object-Oriented Development. In descending order of popularity, the quarks are: Inheritance, Object, Class, Encapsulation, Method, Message Passing, Polymorphism, Abstraction

* Dynamic dispatch ndash; 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.

* Encapsulation (object-oriented programming)|Encapsulation (or multi-methods, in which case the state is kept separate)

* Object inheritance (object-oriented programming)|inheritance (or Delegation (programming)#As a language feature|delegation)

* Open recursion ndash; 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 Name binding|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
Object-oriented programming language - Fundamental features and concepts Similarly, in his 2003 book, Concepts in programming languages, John C

* Class (computer science)|Classes of objects (object constructors)
Object-oriented programming language - Fundamental features and concepts * Class (computer science)|Classes of objects (object constructors)

* Instance (computer science)|Instances of classes (objects, which have been constructed via a class)

* Method (computer science)|Methods which act on the attached objects.
Object-oriented programming language - Fundamental features and concepts * Method (computer science)|Methods which act on the attached objects.

* Abstraction (computer science)|Abstraction
Object-oriented programming language - Fundamental features and concepts * Abstraction (computer science)|Abstraction

Object-oriented programming language - Additional features
; Encapsulation enforces modularity

: Encapsulation refers to the creation of self-contained modules that bind processing functions to the data. These user-defined data types are called classes, and one instance of a class is an object. For example, in a payroll system, a class could be Manager, and Pat and Jan could be two instances (two objects) of the Manager class. Encapsulation ensures good code modularity, which keeps routines separate and less prone to conflict with each other.

: Classes are created in hierarchies, and inheritance lets the structure and methods in one class pass down the hierarchy. That means less programming is required when adding functions to complex systems. If a step is added at the bottom of a hierarchy, only the processing and data associated with that unique step must be added. Everything else above that step is inherited. The ability to reuse existing objects is considered a major advantage of object technology.

: Object-oriented programming lets programmers create procedures for objects whose exact type is not known until runtime. For example, a screen cursor may change its shape from an arrow to a line depending on the program mode. The routine to move the cursor on screen in response to mouse movement can be written for cursor, and polymorphism lets that cursor take simulating system behaviour.

Object-oriented programming language - Formal semantics
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.

* abstract data types (which have existential types) allow the definition of Module (programming)|modules but these do not support dynamic dispatch

* Record (computer science)|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-sub|System F : that deal with mutable objects have been studied; 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] for formal definitions of many OOP concepts and constructs), and often diverge widely

Object-oriented programming language - OOP languages
Smalltalk (1972 to 1980) is arguably the canonical example, and the one with which much of the theory of object-oriented programming was developed

* 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

* Languages designed mainly for OO programming, but with some procedural elements. Examples: Object Pascal|Delphi/Object Pascal, C++, Java (programming language)|Java, C Sharp (programming language)|C#, VB.NET, Python (programming language)|Python.

* Languages that are historically Procedural programming|procedural languages, but have been extended with some OO features. Examples: Pascal (programming language)|Pascal, Visual Basic (derived from BASIC), MATLAB, Fortran, Perl, COBOL 2002, PHP, ABAP, Ada (programming language)|Ada 95.

* Languages with most of the features of objects (classes, methods, inheritance), but in a distinctly original form. Examples: Oberon (programming language)|Oberon (Oberon-1 or Oberon-2).

* Languages with abstract data type support, but not all features of object-orientation, sometimes called object-based|object-based languages. Examples: Modula-2, Pliant, CLU (programming language)|CLU.

* Chameleon languages that support multiple paradigms, including OO. Tcl stands out among these for TclOO, a hybrid object system that supports both prototype-based programming and class-based OO.

Object-oriented programming language - OOP in dynamic languages
In recent years, object-oriented programming has become especially popular in dynamic programming languages. Python (programming language)|Python, Ruby (programming language)|Ruby and Groovy (programming language)|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 6.

Object-oriented programming language - Design patterns
Challenges of object-oriented design are addressed by several methodologies. Most common is known as the Design Patterns (book)|design patterns codified by Gamma et al.. More broadly, the term design pattern (computer science)|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.

Object-oriented programming language - Inheritance and behavioral subtyping
It is intuitive to assume that inheritance creates a program semantics|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

Object-oriented programming language - Gang of Four design patterns
Design Patterns (book)|Design Patterns: Elements of Reusable Object-Oriented Software is an influential book published in 1995 by Erich Gamma, Richard Helm, Ralph Johnson (computer scientist)|Ralph Johnson, and John Vlissides, often referred to humorously as the Gang of Four. Along with exploring the capabilities and pitfalls of object-oriented programming, it describes 23 common programming problems and patterns for solving them.

* Creational patterns (5): Factory method pattern, Abstract factory pattern, Singleton pattern, Builder pattern, Prototype pattern

* Structural patterns (7): Adapter pattern, Bridge pattern, Composite pattern, Decorator pattern, Facade pattern, Flyweight pattern, Proxy pattern

Object-oriented programming language - OOP and control flow
OOP was developed to increase the Code reuse|reusability and Software maintenance|maintainability of source code. Transparent representation of the control flow had no priority and was meant to be handled by a compiler. With the increasing relevance of parallel hardware and Thread (computer science)|multithreaded coding, developing transparent control flow becomes more important, something hard to achieve with OOP.

Object-oriented programming language - Criticism
The OOP paradigm has been criticised for a number of reasons, including not meeting its stated goals of reusability and modularity, and for overemphasizing one aspect of software design and modeling (data/objects) at the expense of other important aspects (computation/algorithms).

Luca Cardelli has claimed that OOP code is intrinsically less efficient than procedural code, that OOP can take longer to compile, and that OOP languages have extremely poor modularity properties with respect to class extension and modification, and tend to be extremely complex

Christopher J. Date stated that critical comparison of OOP to other technologies, relational in particular, is difficult because of lack of an agreed-upon and rigorous definition of OOP;C. J. Date, Introduction to Database Systems, 6th-ed., Page 650 however, Date and Darwen have proposed a theoretical foundation on OOP that uses OOP as a kind of customizable Data type|type system to support RDBMS.C. J. Date, Hugh Darwen. Foundation for Future Database Systems: The Third Manifesto (2nd Edition)

Paul Graham (computer programmer)|Paul Graham has suggested that OOP's popularity within large companies is due to large (and frequently changing) groups of mediocre programmers. According to Graham, the discipline imposed by OOP prevents any one programmer from doing too much damage.

Steve Yegge noted that, as opposed to functional programming:[ Stevey's Blog Rants]

Eric S. Raymond, a Unix programmer and open-source software advocate, has been critical of claims that present object-oriented programming as the One True Solution, and has written that object-oriented programming languages tend to encourage thickly-layered programs that destroy transparency. Raymond contrasts this to the approach taken with Unix and the C (programming language)|C programming language.

Inheritance (object-oriented programming)
In object-oriented programming (OOP), 'inheritance' is when an object or class is based on another object or class, using the same implementation (inheriting from a class) or specifying implementation to maintain the same behavior (realizing an interface; inheriting behavior)

Inheritance #Inheritance vs subtyping|should not be confused with subtyping

Inheritance is contrasted with object composition, where one object contains another object (or objects of one class contain objects of another class); see composition over inheritance. Composition implements a has-a relationship, in contrast to the is-a relationship of subtyping.

Inheritance (object-oriented programming) - Types of inheritance
There are various types of inheritance, depending on paradigm and specific language. A fundamental difference is whether one can inherit from only a single other object or class, which is known as single inheritance, or whether one can inherit from multiple other objects or classes, which is known as multiple inheritance. The hierarchy in single inheritance is a Tree (set theory)|tree, while in multiple inheritance it is a Lattice (order)|lattice.

'Classical inheritance' is used in class-based programming, where objects are defined by Class (computer programming)|classes, and classes can inherit attributes and implementation (i.e., previously coded algorithms associated with a class) from pre-existing classes called base classes, superclasses, or parent classes. The resulting classes are known as derived classes, subclasses, or child classes, and the resulting hierarchy is known as a class hierarchy.

Differential inheritance is used in prototype-based programming, where objects inherit directly from other objects.

Inheritance (object-oriented programming) - Subclasses and superclasses
A Subclass, derived class, heir class, or child class is a Modular programming|modular, derivative class that inherits one or more Programming language|language entities from one or more other classes (called superclasses, base classes, or parent classes)

In some languages a class may be declared as Class_(computer_programming)#Non-subclassable|uninheritable by adding certain class modifiers to the class declaration

The sealed class has no subclasses, so it can be easily deduced at compile time that references or pointers to objects of that class are actually referencing instances of that class and not instances of subclasses (they don't exist) or instances of superclasses (upcasting a reference type violates the type system)

Inheritance (object-oriented programming) - Methods that cannot be overridden
Just as classes may be sealed/finalized method declarations may contain method modifiers that prevent the method from being overridden (i.e

Inheritance (object-oriented programming) - Virtual methods
If the superclass method is a virtual method, then invocations of the superclass method will be Dynamic dispatch|dynamically dispatched

Inheritance (object-oriented programming) - Overriding
This process is usually called override (object-oriented programming)|overriding

Inheritance is similar to but distinct from subtyping.

Subtyping enables a given type to be substituted for another type or abstraction, and is said to establish an 'is-a' relationship between the subtype and some existing abstraction, either implicitly or explicitly, depending on language support

In programming languages that do not support inheritance as a subtype polymorphism|subtyping mechanism, the relationship between a base class and a derived class is only a relationship between implementations (a mechanism for code reuse), as compared to a relationship between data type|types

(Compare Connotation (semiotics)|connotation/denotation.) In some OOP languages, the notions of code reuse and subtyping coincide because the only way to declare a subtype is to define a new class that inherits the implementation of another.

Sometimes inheritance-based design is used instead of roles

One consequence of separation of roles and superclasses is that this cleanly separates compile-time and run time (program lifecycle phase)|run-time aspects of the object system. Inheritance is then clearly a compile-time construct. It does influence the structure of many objects at run-time, but the different kinds of structure that can be used are already fixed at compile-time.

To model the example of Person as an employee with this method, the modeling ensures that a Person class can only contain operations or data that are common to every Person instance regardless of where they are used

The difference between roles and classes is unclear if one assumes Referential transparency (computer science)|referential transparency because roles are types of references and classes are types of the referred-to objects.

Inheritance (object-oriented programming) - Alternatives
While inheritance is widely used, there are various alternatives. Some people advocate object composition instead of inheritance; see composition over inheritance. Similar mechanisms to inheritance (reusing implementation) can be achieved by mixins and Trait (computer programming)|traits.

Comparison of programming languages (object-oriented programming)
This 'Comparison of programming languages' compares how object-oriented programming languages such as C++, Python (programming language)|Python, Perl, Java (programming language)|Java, Object Pascal and others manipulate data structures.

List of object-oriented programming terms
This is a list of terms found in object-oriented programming. Some are related to object-oriented programming and some are not.

List of object-oriented programming terms - C
* Object (computer science)|Class object

* Container (data structure)|Collection class

* Covariance and contravariance (computer science)|Contravariance

List of object-oriented programming terms - E
* European Conference on Object-Oriented Programming

List of object-oriented programming terms - H
* Multi-paradigm programming language|Hybrid language

List of object-oriented programming terms - I
* Immutable object (also called immutable value)

* inline expansion|Inline function

* Unified Modeling Language|Interaction diagram

* Interface (computing)|Interface

List of object-oriented programming terms - L
* Dynamic binding (computer science)|Late binding

List of object-oriented programming terms - M
* Members, any contents of a class: Attributes, Method (computer science)|Methods and Inner classes

List of object-oriented programming terms - O
* OOPSLA – annual conference on Object-Oriented Programming Systems Language and Application

List of object-oriented programming terms - P
* , a way of Encapsulation (object-oriented programming)|encapsulation in object-oriented programming

* , a way of Encapsulation (object-oriented programming)#Encapsulation|encapsulation in object-oriented programming

* Pseudo-variable

* Virtual function|Pure virtual function (also called pure virtual method)

List of object-oriented programming terms - R
* Run-time type information

List of object-oriented programming terms - S
* Type system|Statically typed language, as opposed to Dynamically typed language

* Strongly-typed programming language

* Subclass (computer science)|Subclass (also called child class or derived class)

* Coupling (computer science)|Subclass coupling

* Substitutability, principle of

* Superclass (computer science)|Superclass (also called parent class or base class)

List of object-oriented programming terms - T
* Trait (computer science)|Trait

List of object-oriented programming terms - V
* Verb: to program to (see discussion)

* Virtual function (also called virtual method)

* Virtual function pointer (also called virtual method pointer)

* Virtual inheritance (Object Oriented Programming)

* Virtual method table (also called vtable, virtual function table or virtual method table)

Procedural code - Comparison with object-oriented programming
The most important distinction is that while procedural programming uses procedures to operate on data structures, object-oriented programming bundles the two together, so an object, which is an instance of a class, operates on its own data structure

*Ada (programming language)|Ada 95
List of object-oriented programming languages - Languages with object-oriented features *Ada (programming language)|Ada 95

*BETA (programming language)|BETA
List of object-oriented programming languages - Languages with object-oriented features *BETA (programming language)|BETA

*Blue (programming language)|Blue
List of object-oriented programming languages - Languages with object-oriented features *Blue (programming language)|Blue

*Boo (programming language)|Boo
List of object-oriented programming languages - Languages with object-oriented features *Boo (programming language)|Boo

*C Sharp (programming language)|C#
List of object-oriented programming languages - Languages with object-oriented features *C Sharp (programming language)|C#

*Chapel (programming language)|Chapel
List of object-oriented programming languages - Languages with object-oriented features *Chapel (programming language)|Chapel

*Clarion (programming language)|Clarion
List of object-oriented programming languages - Languages with object-oriented features *Clarion (programming language)|Clarion

*CLU (programming language)|CLU
List of object-oriented programming languages - Languages with object-oriented features *CLU (programming language)|CLU

*Cobra (programming language)|Cobra
List of object-oriented programming languages - Languages with object-oriented features *Cobra (programming language)|Cobra

*Cool (programming language)|COOL
List of object-oriented programming languages - Languages with object-oriented features *Cool (programming language)|COOL

*Curl (programming language)|Curl
List of object-oriented programming languages - Languages with object-oriented features *Curl (programming language)|Curl

*D (programming language)|D
List of object-oriented programming languages - Languages with object-oriented features *D (programming language)|D

*Dylan (programming language)|Dylan
List of object-oriented programming languages - Languages with object-oriented features *Dylan (programming language)|Dylan

*E (programming language)|E
List of object-oriented programming languages - Languages with object-oriented features *E (programming language)|E

*Eiffel (programming language)|Eiffel
List of object-oriented programming languages - Languages with object-oriented features *Eiffel (programming language)|Eiffel

*Falcon (programming language)|Falcon
List of object-oriented programming languages - Languages with object-oriented features *Falcon (programming language)|Falcon

*Fancy (programming language)|Fancy
List of object-oriented programming languages - Languages with object-oriented features *Fancy (programming language)|Fancy

*FPr_(programming_language)|FPr
List of object-oriented programming languages - Languages with object-oriented features *FPr_(programming_language)|FPr

*F-Script (programming language)|F-Script
List of object-oriented programming languages - Languages with object-oriented features *F-Script (programming language)|F-Script

*F Sharp (programming language)|F#
List of object-oriented programming languages - Languages with object-oriented features *F Sharp (programming language)|F#

*J (programming language)|J
List of object-oriented programming languages - Languages with object-oriented features *J (programming language)|J

*JADE (programming language)|JADE
List of object-oriented programming languages - Languages with object-oriented features *JADE (programming language)|JADE

*Java (programming language)|Java
List of object-oriented programming languages - Languages with object-oriented features *Java (programming language)|Java

**Groovy (programming language)|Groovy
List of object-oriented programming languages - Languages with object-oriented features **Groovy (programming language)|Groovy

**X10 (programming language)|X10
List of object-oriented programming languages - Languages with object-oriented features **X10 (programming language)|X10

*Lasso (programming language)|Lasso
List of object-oriented programming languages - Languages with object-oriented features *Lasso (programming language)|Lasso

*Lava (programming language)|Lava
List of object-oriented programming languages - Languages with object-oriented features *Lava (programming language)|Lava

*Lingo (programming language)|Lingo
List of object-oriented programming languages - Languages with object-oriented features *Lingo (programming language)|Lingo

*Oberon (programming language)|Oberon (Oberon-1)
List of object-oriented programming languages - Languages with object-oriented features *Oberon (programming language)|Oberon (Oberon-1)

*Oz (programming language)|Oz
List of object-oriented programming languages - Languages with object-oriented features *Oz (programming language)|Oz

*Prototype-based programming|Prototype-based languages
List of object-oriented programming languages - Languages with object-oriented features *Prototype-based programming|Prototype-based languages

**Agora (programming language)|Agora
List of object-oriented programming languages - Languages with object-oriented features **Agora (programming language)|Agora

**Cecil (programming language)|Cecil
List of object-oriented programming languages - Languages with object-oriented features **Cecil (programming language)|Cecil

**Cel (programming language)|Cel
List of object-oriented programming languages - Languages with object-oriented features **Cel (programming language)|Cel

**Etoys (programming language)|Etoys (in Squeak)
List of object-oriented programming languages - Languages with object-oriented features **Etoys (programming language)|Etoys (in Squeak)

**Io (programming language)|Io
List of object-oriented programming languages - Languages with object-oriented features **Io (programming language)|Io

**Lua (programming language)|Lua
List of object-oriented programming languages - Languages with object-oriented features **Lua (programming language)|Lua

**MOO (programming language)|MOO
List of object-oriented programming languages - Languages with object-oriented features **MOO (programming language)|MOO

**Self (programming language)|Self
List of object-oriented programming languages - Languages with object-oriented features **Self (programming language)|Self

*Python (programming language)|Python
List of object-oriented programming languages - Languages with object-oriented features *Python (programming language)|Python

*Revolution (programming language)|Revolution
List of object-oriented programming languages - Languages with object-oriented features *Revolution (programming language)|Revolution

*Ruby (programming language)|Ruby
List of object-oriented programming languages - Languages with object-oriented features *Ruby (programming language)|Ruby

*S (programming language)|S
List of object-oriented programming languages - Languages with object-oriented features *S (programming language)|S

**R (programming language)|R
List of object-oriented programming languages - Languages with object-oriented features **R (programming language)|R

*Scala (programming language)|Scala
List of object-oriented programming languages - Languages with object-oriented features *Scala (programming language)|Scala

**Bistro (programming language)|Bistro
List of object-oriented programming languages - Languages with object-oriented features **Bistro (programming language)|Bistro

*Squirrel (programming language)|Squirrel
List of object-oriented programming languages - Languages with object-oriented features *Squirrel (programming language)|Squirrel

*Swift (programming language)|Swift
List of object-oriented programming languages - Languages with object-oriented features *Swift (programming language)|Swift

**Snit (uses delegation)
List of object-oriented programming languages - Languages with object-oriented features **Snit (uses delegation)

*Vala (programming language)|Vala
List of object-oriented programming languages - Languages with object-oriented features *Vala (programming language)|Vala

Turbo Pascal - Object-oriented programming
From version 5.5 some object-oriented programming features were introduced: classes, inheritance, constructors and destructors. The IDE was already augmented with an object browser interface showing relations between objects and methods and allowing programmers to navigate the modules easily. Borland called its language Object Pascal, which was greatly extended to become the language underlying Embarcadero Delphi|Delphi (which has two separate OOP systems).

Turbo Pascal - Object-oriented programming
The name Object Pascal originated with the Pascal extensions developed by Apple Inc. to program its Apple Lisa|Lisa and Macintosh computers. Pascal originator Niklaus Wirth consulted in developing these extensions, which built upon the record (computer science)|record type already present in Pascal.

Object-oriented user interface - Relationship to object-oriented programming
Although there are many conceptual parallels between OOUIs and object-oriented programming, it does not follow that an OOUI has to be implemented using an object-oriented programming language.

The guidelines for IBM Common User Access|IBM's Common User Access (CUA), (possibly the most comprehensive attempt at defining a standard for OOUI design) stated that 'while object-oriented programming can facilitate the development of an object-oriented user interface, it is not a pre-requisite. An object-oriented user interface can be developed with more traditional programming languages and tools.' IBM, Common User Access - Guide to User Interface Design. 1991, IBM: Cary, North Carolina.

However, there are strong synergies. Larry Tesler, who left Xerox PARC in 1980 to join Apple Inc.|Apple underlined the relationship:

Thunk (compatibility mapping) - Object-oriented programming
Thunks are useful in object-oriented programming platforms that allow a Class (computer programming)|class to multiple inheritance|inherit multiple interfaces, leading to situations where the same Method (computer programming)|method might be called via any of several interfaces. The following code illustrates such a situation in C++.

Thunk (compatibility mapping) - Object-oriented programming
virtual int access() return this-/sourceref name=BS99ref name=DH01references /

For More Information, Visit:
The Art of Service

Object-Oriented Programming

Similar presentations

Presentation on theme: "Object-Oriented Programming"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Object-Oriented Programming

Similar presentations

Presentation on theme: "Object-Oriented Programming"— Presentation transcript:

Similar presentations

About project

Feedback