Object-Oriented Programming, Characteristics and Practices
Object-Oriented Programming made its first appearance in the early 1960s. It was Alan Kay, working at the Xerox Palo Alto Research Center, who first introduced the original specifications by drawing influences from Simula and pre-existing abstractions in LISP. The resulting programming language, Smalltalk, introduced the term, features and concepts of object-oriented languages and provided a paradigm for many such languages to follow, which collectively changed numerous aspects of computer science.
While there is no agreed formalization as to what characteristics constitute an object-oriented language, the main features of most include classes and objects, which are class instances. The concept of classes is a very important one in object-oriented programming (hereinafter referred to as OOP). Drawing from our need to categorize elements around us, a class represents something nominalized and defines properties and attributes for its instances. In other words, a class defines constituent members which enable its instances to have state and behaviour 1. Another concept of OOP, directly related to classes and objects, which introduced great benefits in software development is inheritance, which allows for properties and attributes to be transferred between classes, be they user-generated or part of the language. In general, an object-based language is object-oriented if its objects belong to classes and class hierarchies may be defined by an inheritance mechanism 2.
Even though all attributes between classes are communicated throughout the program in a top-down fashion, the interdependencies between separately-written modules are minimised by defining strict external interfaces. This facet of OOP is called data encapsulation. Data encapsulation is a language mechanism that restricts access to some data in the objects’ components 3, therefore forbidding other methods to modify it. This greatly facilitates program evolution and maintenance, while also being a key feature for large systems and long-lived data.4. Apart from data encapsulation, another main feature of OOP is polymorphism. Polymorphism is derived from a Greek word meaning “having multiple forms” and enables operations of the same name on object variables of different types. The calling code does not need to know the exact type of the object and the nature of the operation is determined at run-time 5. This process is called dynamic binding, while assigning multiple meanings to the names of functions and operators is referred to as overloading.
All these features and capabilities have led to widespread increase in the use of OOP throughout the years. As it grew in popularity, numerous debates and discussions emerged regarding the advantages and pitfalls of object-oriented compared to procedural and functional programming. The main benefits of OOP include modularity, reusability of code, and information-hiding 6. Modularity in OOP means that classes can be implemented and maintained separately from the rest of the source-code. This, along with information-hiding, which is a direct consequence of data encapsulation, allow for easier debugging of source code and is generally less of a risk in large-scale projects, which is why it is preferred in large companies. On the other hand, OOP has been criticised for having poor modularity properties 7, its non-orthogonality, and for often being the culprit for complicated code among others.
The notions and features that were established by object-oriented languages modified many preexisting concepts in computer science and led programmers and scholars to approach problem-solving from a different perspective, while helping create a new software industry at the same time. The introduction of objects changed the way data was structured and handled inside programs and led us to programming techniques very similar to our perception of real life, where everything can be perceived as such. This radical approach of OOP to commonplace problems in programming is what has made it a centerpiece in the programming language landscape in the past, present, and hopefully for many years to come.
BIBLIOGRAPHY
• T. Rentsch. 1982. “Object oriented programming”, ACM Sigplan Notices, Vol. 17, No. 9, pp. 51-57.
• B. Stroustrup. 1988. “What is Object-Oriented Programming?”, Software, IEEE, Vol. 5, No. 3, pp.10-20
• B. Müller. 1993. “Is object-oriented programming structured programming?”, ACM SIGPLAN Notices, Vol. 28, No. 9, pp. 57-66.
• M. Kölling. 1999. “The Problem of Teaching Object-Oriented Programming, Part 1: Languages”, Journal of Object-Oriented Programming, Vol. 11, No.8, pp. 8-15.
• A. Snyder. 1986. “Encapsulation and Inheritance in Object-Oriented Programming Languages”, ACM SIGPLAN, Vol. 21, No. 11, pp. 38-45.
• P. Canning et al. 1989. “F-bounded polymorphism for object-oriented programming”, Proceedings of the fourth international conference on Functional programming languages and computer architecture, ACM, pp. 273-280. G. Broch. 1986. “Object-Oriented Development”, IEEE Transactions on Software Engineering, Vol. 12, No. 2, pp. 211-221.
• L. Cardelli, P. Wegner. 1985. “On Understanding Types, Data Abstraction, and Polymorphism”, Computing Surveys, Vol. 17, No. 4, pp. 471-522.
-
E. Gamma et al., Design Patterns: Elements of Reusable Object-Oriented Software. (1st ed.), Addison Weasley, 1995, p. 14. ↩
-
P. Wegner. 1987. “Dimensions of Object-Based Language Design”, ACM, Vol. 22, No. 12, pp. 168-182. ↩
-
J. Mitchell. Concepts in Programming Languages, Cambridge University Press, 2003, p. 522. ↩
-
A. Snyder. 1986. “Encapsulation and Inheritance in Object-Oriented Programming Languages”, Proc. of ACM Conf. on Object-Oriented Programming, Systems, Languages and Applications, pp. 38-45. ↩
-
Wikipedia. Polymorphism in Object-Oriented Programming [Online]. Available. [Accessed 17 Nov. 2012]. ↩
-
L. Cardelli. 1996. “Bad engineering properties of object-oriented languages.” ACM Computing Surveys (CSUR), Vol. 28, p. 150. ↩
-
Russell. Object-Oriented Programming Concepts [Online]. Available. [Accessed 18 Nov. 2012] ↩