Object-oriented programming

From Wikipedia, the free encyclopedia
  (Redirected from Object Oriented Programming)
Jump to: navigation, search
"Object-oriented" redirects here. For other meanings of object-oriented, see Object-orientation.
"Object-oriented programming language" redirects here. For a list of object-oriented programming languages, see List of object-oriented programming languages.

Object-oriented programming (OOP) is a programming paradigm based on the concept of "objects", which may contain data, in the form of fields, often known as attributes; and code, in the form of procedures, often known as methods. A feature of objects is that an object's procedures can access and often modify the data fields of the object with which they are associated (objects have a notion of "this" or "self"). In OOP, computer programs are designed by making them out of objects that interact with one another.[1][2] There is significant diversity of OOP languages, but the most popular ones are class-based, meaning that objects are instances of classes, which typically also determine their type.

Many of the most widely used programming languages (such as C++, Java, Python etc.) are multi-paradigm programming languages that support object-oriented programming to a greater or lesser degree, typically in combination with imperative, procedural programming. Significant object-oriented languages include Java, C++, C#, Python, PHP, Ruby, Perl, Delphi, Objective-C, Swift, Scala, Common Lisp, and Smalltalk.


Object-oriented Programming uses objects, but not all of the associated techniques and structures are supported directly in languages that claim to support OOP. The features listed below are, however, common among languages considered strongly class- and object-oriented (or multi-paradigm with OOP support), with notable exceptions mentioned.[3][4][5][6]

Shared with non-OOP predecessor languages[edit]

Object-oriented programming languages typically share low-level features with high-level procedural programming languages (which were invented first). The fundamental tools that can be used to construct a program include:

Modular programming support provides the ability to group procedures into files and modules for organizational purposes. Modules are namespaced so code in one module will not be accidentally confused with the same procedure or variable name in another file or module.

Objects and classes[edit]

Languages that support object-oriented programming typically use inheritance for code reuse and extensibility in the form of either classes or prototypes. Those that use classes support two main concepts:

  • Classes – the definitions for the data format and available procedures for a given type or class of object; may also contain data and procedures (known as class methods) themselves, i.e. classes contains the data members and member functions
  • Objects – instances of classes







Dynamic dispatch/message passing[edit]

It is the responsibility of the object, not any external code, to select the procedural code to execute in response to a method call, typically by looking up the method at run time in a table associated with the object. This feature is known as dynamic dispatch, and distinguishes an object from an abstract data type (or module), which has a fixed (static) implementation of the operations for all instances. If there are multiple methods that might be run for a given name, it is known as multiple dispatch.



Encapsulation is an Object Oriented Programming concept that binds together the data and functions that manipulate the data, and that keeps both safe from outside interference and misuse. Data encapsulation led to the important OOP concept of data hiding.


Composition, inheritance, and delegation[edit]

Objects can contain other objects in their instance variables; this is known as object composition. For example, an object in the Employee class might contain (point to) an object in the Address class, in addition to its own instance variables like "first_name" and "position". Object composition is used to represent "has-a" relationships: every employee has an address, so every Employee object has a place to store an Address object.








Subtyping, a form of polymorphism, is when calling code can be agnostic as to whether an object belongs to a parent class or one of its descendants. For example, a function might call "make_full_name()" on an object, which will work whether the object is of class Person or class Employee. This is another type of abstraction which simplifies code external to the class hierarchy and enables strong separation of concerns.

Open recursion[edit]



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);[9][10] Alan Kay was later to cite a detailed understanding of LISP internals as a strong influence on his thinking in 1966.[11] Another early MIT example was Sketchpad created by Ivan Sutherland in 1960–61; in the glossary of the 1963 technical report based on his dissertation about Sketchpad, Sutherland defined notions of "object" and "instance" (with the class concept covered by "master" or "definition"), albeit specialized to graphical interaction.[12] Also, an MIT ALGOL version, AED-0, established a direct link between data structures ("plexes", in that dialect) and procedures, prefiguring what were later termed "messages", "methods", and "member functions".[13][14]

The formal programming concept of objects was introduced in the mid-1960s with 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.[15][not in citation given][citation needed][16][not in citation given][citation needed][17][18][19]

Simula 67 was influenced by SIMSCRIPT and C.A.R. "Tony" Hoare's proposed "record classes".[13][20] Simula introduced the notion of classes and instances or objects (as well as subclasses, virtual procedures, coroutines, and discrete event simulation) as part of an explicit programming paradigm. The language also used automatic garbage collection that had been invented earlier for the functional programming language Lisp. Simula was used for physical modeling, such as models to study and improve the movement of ships and their content through cargo ports. The ideas of Simula 67 influenced many later languages, including Smalltalk, derivatives of LISP (CLOS), Object Pascal, and C++.

The Smalltalk language, which was developed at Xerox PARC (by Alan Kay and others) in the 1970s, introduced the term object-oriented programming to represent the pervasive use of objects and messages as the basis for computation. Smalltalk creators were influenced by the ideas introduced in Simula 67, but Smalltalk was designed to be a fully dynamic system in which classes could be created and modified dynamically rather than statically as in Simula 67.[21] Smalltalk and with it OOP were introduced to a wider audience by the August 1981 issue of Byte Magazine.


In 1985, Bertrand Meyer produced the first design of the Eiffel language. Focused on software quality, Eiffel is among the purely object-oriented languages, but differs in the sense that the language itself is not only a programming language, but a notation supporting the entire software lifecycle. Meyer described the Eiffel software development method, based on a small number of key ideas from software engineering and computer science, in Object-Oriented Software Construction. Essential to the quality focus of Eiffel is Meyer's reliability mechanism, Design by Contract, which is an integral part of both the method and language.





OOP languages[edit]


OOP in dynamic languages[edit]



OOP in a network protocol[edit]


  • Fields defining the data values that form messages, such as their length, codepoint and data values.


Design patterns[edit]

Challenges of object-oriented design are addressed by several methodologies. Most common is known as the design patterns codified by Gamma et al.. More broadly, the term "design patterns" can be used to refer to any general, repeatable solution to a commonly occurring problem in software design. Some of these commonly occurring problems have implications and solutions particular to object-oriented development.

Inheritance and behavioral subtyping[edit]


Gang of Four design patterns[edit]


The book describes the following patterns:

Object-orientation and databases[edit]



Real-world modeling and relationships[edit]




OOP and control flow[edit]


Responsibility- vs. data-driven design[edit]


SOLID and GRASP guidelines[edit]













Steve Yegge noted that, as opposed to functional programming:[47]



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.[48] Raymond compares this unfavourably to the approach taken with Unix and the C programming language.[48]

Rob Pike, a programmer involved in the creation of UTF-8 and Go, has called object-oriented programming "the Roman numerals of computing"[49] and has said that OOP languages frequently shift the focus from data structures and algorithms to types.[50] Furthermore, he cites an instance of a Java professor whose "idiomatic" solution to a problem was to create six new classes, rather than to simply use a lookup table.[51]

Formal semantics[edit]




See also[edit]


Modeling languages[edit]


  2. ^ Lewis, John; Loftus, William (2008). Java Software Solutions Foundations of Programming Design 6th ed. Pearson Education Inc. ISBN 0-321-53205-8. , section 1.6 "Object-Oriented Programming"
  8. ^ Jacobsen, Ivar; Magnus Christerson; Patrik Jonsson; Gunnar Overgaard (1992). Object Oriented Software Engineering. Addison-Wesley ACM Press. pp. 43–69. ISBN 0-201-54435-0. 
  10. ^ McCarthy, John; Abrahams, Paul W.; Edwards, Daniel J.; Hart, swapnil d.; Levin, Michael I. (1962). LISP 1.5 Programmer's Manual (PDF). MIT Press. p. 105. ISBN 0-262-13011-4. Object — a synonym for atomic symbol 
  11. ^ "Dr. Alan Kay on the Meaning of "Object-Oriented Programming"". 2003. Retrieved 11 February 2010. 
  12. ^ Sutherland, I. E. (30 January 1963). "Sketchpad: A Man-Machine Graphical Communication System" (PDF). Technical Report No. 296, Lincoln Laboratory, Massachusetts Institute of Technology via Defense Technical Information Center (stinet.dtic.mil). Retrieved 3 November 2007. 
  13. ^ a b The Development of the Simula Languages, Kristen Nygaard, Ole-Johan Dahl, p.254 Uni-kl.ac.at
  15. ^ Dahl, Ole Johan (2004). "The Birth of Object Orientation: the Simula Languages" (PDF). doi:10.1007/978-3-540-39993-3_3. Retrieved 9 June 2016. 
  17. ^ Wilson, Leslie B.; Robert G. Clark (2001). Comparative Programming Languages (3 ed.). Addison-Wesley. p. 35. ISBN 978-0-201-71012-0. Simula was based on Algol 60 with one very important addition – the class concept. It is possible to declare a class, generate objects of that class, name these objects and form a hierarchical structure of class declarations. 
  18. ^ Wilson, Leslie B.; Robert G. Clark (2001). Comparative Programming Languages (3 ed.). Addison-Wesley. p. 35. ISBN 978-0-201-71012-0. The impact of Simula on the design of programming languages is large as it is the original object-oriented language. The class concept has been taken over and used in many later languages, such as C++, Ada, Smalltalk, Eiffel and Java. 
  19. ^ Bal, Henri E.; Dick Grune (1994). Programming Language Essentials. Addison-Wesley. p. 134. ISBN 0-201-63179-2. Simula was the first language to use a class concept. 
  20. ^ Hoare, C. A. (Nov 1965). "Record Handling". ALGOL Bulletin (21): 39–69. doi:10.1145/1061032.1061041. 
  23. ^ FoxPro History web site: Foxprohistory.org
  24. ^ 1995 Reviewers Guide to Visual FoxPro 3.0: DFpug.de
  25. ^ https://books.google.co.uk/books?id=MHmqfSBTXsAC&pg=PA16&lpg=PA16
  26. ^ "The Emerald Programming Language". 2011-02-26. 
  27. ^ Neward, Ted (26 June 2006). "The Vietnam of Computer Science". Interoperability Happens. Retrieved 2 June 2010. 
  28. ^ Meyer, Second Edition, p. 230
  30. ^ Wirth, Nicklaus (2006). "Good Ideas, Through the Looking Glass" (PDF). Computer (magazine). 39 (1): 28–39. Retrieved 2016-10-02. 
  31. ^ Yegge, Steve (30 March 2006). "Execution in the Kingdom of Nouns". steve-yegge.blogspot.com. Retrieved 3 July 2010. 
  32. ^ Boronczyk, Timothy (11 June 2009). "What's Wrong with OOP". zaemis.blogspot.com. Retrieved 3 July 2010. 
  33. ^ Ambler, Scott (1 January 1998). "A Realistic Look at Object-Oriented Reuse". www.drdobbs.com. Retrieved 4 July 2010. 
  35. ^ James, Justin (1 October 2007). "Multithreading is a verb not a noun". techrepublic.com. Retrieved 4 July 2010. 
  36. ^ Shelly, Asaf (22 August 2008). "HOW TO: Multicore Programming (Multiprocessing) Visual C++ Class Design Guidelines, Member Functions". support.microsoft.com. Retrieved 4 July 2010. 
  38. ^ a b Cardelli, Luca (1996). "Bad Engineering Properties of Object-Oriented Languages". ACM Comput. Surv. ACM. 28 (4es): 150. doi:10.1145/242224.242415. ISSN 0360-0300. Retrieved 21 April 2010. 
  39. ^ a b Armstrong, Joe. In Coders at Work: Reflections on the Craft of Programming. Peter Seibel, ed. Codersatwork.com, Accessed 13 November 2009.
  45. ^ Krubner, Lawrence. "Object Oriented Programming is an expensive disaster which must end". smashcompany.com. Retrieved 14 October 2014. 
  46. ^ Graham, Paul. "Why ARC isn't especially Object-Oriented.". PaulGraham.com. Retrieved 13 November 2009. 
  47. ^ Stevey's Blog Rants
  48. ^ a b Eric S. Raymond (2003). "The Art of Unix Programming: Unix and Object-Oriented Languages". Retrieved 2014-08-06. 
  49. ^ Pike, Rob (2004-03-02). "[9fans] Re: Threads: Sewing badges of honor onto a Kernel". comp.os.plan9 (Mailing list). Retrieved 2016-11-17. 
  50. ^ Pike, Rob (2012-06-25). "Less is exponentially more". Retrieved 2016-10-01. 
  51. ^ Pike, Rob (2012-11-14). "A few years ago I saw this page". Retrieved 2016-10-01. 
  53. ^ a b Abadi, Martin; Cardelli, Luca (1996). A Theory of Objects. Springer-Verlag New York, Inc. ISBN 0-387-94775-2. Retrieved 21 April 2010. 

Further reading[edit]

External links[edit]