Object Oriented Programming

OBJECT ORIENTED
PROGRAMMING

"The new culture of software development" (Bertrand Meyer).

"Everything is an object" (Alan Kay)

"An object has state, behavior, and identity" (Grady Booch).

The Object Paradigm
Object Oriented Programming (OOP) is a programming paradigm that uses objects as its main abstraction. An object is a software component composed of data and code. It consists of several procedures (called methods) through which the object's internal data is accessed. Objects communicate with each other by means of messages.

OOP has emerged strongly in recent times and is seen as a breakthrough in software engineering, comparable to what structured programming once was. Some have presented it as a panacea and as the "definitive paradigm". Because of its diffusion and popularization, it has been described as "The new culture of software development" [Meyer, 1990].

The software world is built primarily on OOP. This includes web applications, enterprise software, network protocols, etc.

OOP concepts

Class.
A class is a type of objects. It is a "template" that generates objects.
Object.
An object is an instance of a class.
Messages.
It is the communication system between objects. Objects communicate dynamically at runtime. By means of messages objects can be created, modified and destroyed dynamically.
Attributes.
They are the internal data of classes and objects.
Event.
An internal or external event produced in the system such as a user interaction, a message sent by an object, or the reaction produced in the receiving object.
Method.
It is a procedure associated to a class and that is executed by the reception of messages. The methods of a class are inherited by the objects of that class and the classes of lower rank (subclasses).
Encapsulation.
Data abstraction is used in objects. That is, the internal data of an object is hidden from the user. The user can only access them through methods, which constitute the public interface.
Inheritance.
Classes are structured in the form of a hierarchical tree. The upper classes are more general and the lower classes are more particular, detail classes. A class inherits attributes and methods from higher classes. It is possible to speak of superclasses and subclasses, superobjects and subobjects.
Behavior of an object.
It is defined by the methods that are activated in response to received messages. This behavior can be internal (modification of internal attributes) or external (sending messages to other objects).
Polymorphism.
It is the ability of an object to exhibit different behaviors depending on the arguments passed to the methods. An object can receive different types of messages. The same message can produce different effects on different objects. It allows operations with the same name but different semantics depending on the arguments. This is called "overloading" (semantics).
State of an object.
It is the formed by a set of attributes (name-value pairs) of that object.
Identity.
An attribute, property, or identifier of an object that differentiates it from the rest.
Owner.
Direct access to common data is rejected. Only the owner of a data (whether common or not) can change the data. Other objects can access or change the data by sending a message to the owner object.
Dynamic binding.
The ability of an object to decide to which other object it sends a message and which particular method should be executed.

Advantages of OOP

Higher semantic level.
OOP represents a closer approximation to the model of the mind, since the semantic level is higher when thinking in terms of:
1. Objects.
  Object is a basic mental pattern associated with the right side of the brain.
2. Classes.
  In this second aspect, it is a matter of thinking, not only in objects, but also in terms of types or classes, i.e., with categories. This involves connecting with another basic feature of the mind: that of associating each object with one or more categories, of which the object is a particular instance.
3. Data abstraction.
  With this mechanism, a distinction is provided between the specification (the "what") and the implementation (the "how"). The "what" implies a higher level of awareness than the "how", which is a level of detail.
Data-process integration.
In OOP, objects and classes integrate attributes (data) and methods (processes).
Generalization.
OOP encourages generalization by creating project-independent objects and classes that are more general than what would be needed to solve a particular problem.

OOP can be considered as the search for generic developments through processes of abstraction of classes and objects. Classes and objects become more generic the higher their level in the hierarchy.
Reuse.
In OOP, emphasis is placed on a design based on modules or components that can be reused in different software systems.

Inheritance promotes reusability by allowing new classes to be created through additions (of new attributes and methods) and substitutions (of inherited attributes and methods) in two ways:
1. Ascending. Classes are extended to give them more generality.
2. Descending. The classes are specialized to adapt them to particular cases.
Flexibility of execution.
The object and method to be executed is determined at runtime.

Disadvantages of OOP

Lack of theoretical basis.
There is neither a theoretical basis nor a formal and rigorous definition of OOP. Different programming languages interpret it differently. There is no direct relationship between the OOP paradigm and OLO (Object Oriented Language). A consensus definition of an object theory has not been reached.
Restrictive paradigm.
The OOP severely limits freedom, expressiveness and creativity by imposing the abstraction of classes and objects, as well as a hierarchical class structure. The abstractions to be used (procedures, functions, objects, events, aspects, etc.) must reflect the structure of the problem. A "mandatory" abstraction should not be imposed. A paradigm is just an ideology, a way of looking at things. But there are many ways of looking at things.

OOP can be a useful model in certain cases, such as modeling real-world objects. You can't use the same tool for all problems. Different problems require different tools. You have to choose the right paradigm for each part of the problem. "Sometimes the elegant implementation is just a function. Not a method. Not a class. Not a framework. Just a function" (John Carmarck, game programmer).
Complexity.
Object-oriented languages are complex, require a long learning curve and are difficult to use. "Object-oriented design is the Roman numerals of computing" (Rob Pike, one of the developers of the Unix system).

The task of programming with the object approach is complex for the following reasons:
1. Learning a LOO requires conceptualizing all elements as objects. This requires a long adaptation to a culture that is foreign to most programmers.
2. A programmer must learn an extensive library of classes before becoming efficient in application development.
3. Difficulty in class design.
  A class is a template used to create new objects. Class definition is currently more of an art than a science. A mistake in establishing hierarchies can have a devastating effect on software projects.
Inheritance.
It is claimed that this is the most powerful concept in OOP, However, it is a limited concept. Inheritance is linear and top-down. Few languages support multiple inheritance, that is, that a class inherits (attributes and methods) from two or more classes. Linear inheritance, in which a class only inherits from the parent class, is the norm.

However, in real life multiple inheritance is very common, because objects can be classified in many ways. For example, cars can be: antique and non-antique. And they can also be sports, luxury or family cars. In this case the classes "sports", "luxury" and "family" have two superclasses: antique and non-antique.

Linear inheritance forces us to categorize things in only one way. Multiple inheritance allows us to consider objects as union of the characteristics of several existing classes.
Performance.
In a system where everything is an object and all interaction is done via messages it is inherently less efficient than procedural code.
Reusability.
OOP has not achieved its goal of reusability of components (classes and objects) because of their complexity. This is mainly due to hierarchical inheritance, since an object needs the class to which it belongs and all higher classes.

"The problem with object-oriented languages is that they drag with them a whole implicit environment. You want a banana, but what you get is a gorilla holding a banana and the whole jungle" (Joe Armstrong, creator of the Arlang language, in "Codes at Work").
Language dependency.
There is no standard LOO yet. Developments made in a certain LOO are not portable, because of their different syntax and semantics. Once the LOO is chosen, switching to another one can be difficult and expensive, because these languages do not support the functionalities equally. For example, C++ supports multiple inheritance, while Smalltalk does not.

In addition, some languages are extensions of procedure-oriented languages (such as C++) or designed under a different paradigm, so they are somewhat conditioned by the original design.
Linguistic inconsistency and ambiguity.
It is inconsistent to call an entity that performs actions an "object". It would be more logical (or make more sense) to call it a "subject", since those who perform actions are the subjects.
"Everything is an object."
Nothing escapes this interpretation. Even arithmetic expressions have their meaning within objects and messages, so that, for example, in 3 + 7, the emphasis is on the object (3) that receives the message +7).

This is forcing a uniformity that does not hold. Indeed, OOP emphasizes the identification and design of objects, which is correct and appropriate when establishing the link with a basic pattern of the mind, but forgets other semantic patterns, which are subject to each particular LOO. The solution to this problem is to extend the semantics.

According to Alexander Syepanov −designer and implementer of software components of the Standard Template Library of C++, and driver of generic programming−, "to say that everything is an object is to say nothing at all."

The concept of "object" is itself ambiguous. "The phrase 'object-oriented' means many things. Half are obvious and half are equivocations" (Paul Graham, known for his work in Lisp).
Static interface.
Although the flexibility of the interface has been increased (by the possibility of invoking different methods), objects are sensitive only to certain types of messages. The interface is predefined, cannot be changed and is therefore static.

Moreover, the methods of an object can be considered as a mere grouping of traditional procedures. And messages do not differ conceptually from traditional calls except for one additional term, which is the name of the object to which the message is addressed (selector).
Lack of control.
There is no complete control of the process, since there is a message manager, an itermediary in charge of passing messages from one object to another.

In fact, for each message to be processed, the manager looks for the selector in the class of the receiving object, then in the superclass, in the superclass of the superclass, etc. until it reaches the root class. And that is assuming the simple case of linear inheritance.
The problem of common data.
When there is data common to several objects, the solution that exists is unnatural: create a class or object and pass messages to it to create or modify that common data.
Process structure.
OOP does not allow modeling process concurrency, a very important issue in software systems.

History of OOP

OOP has its origin in Simula 67 (a revision of Simula I), a programming language designed to perform discrete simulations. This language established the basic concepts of OOP.
The concept of "object" was refined in Smalltalk, a pure object-oriented language developed at Xerox PARC through Simula 67. In Smalltalk, objects are dynamic: they can be created and modified at runtime. Thanks to Smalltalk, OOP became very popular.

Smalltalk is the object-oriented paradigm, just as Lisp is the functional programming paradigm. Smalltalk is considered "the Holy Grail" of OOP. Every object-oriented language is always compared to Smalltalk.

Alan Kay is the creator of Smalltalk. He started developing it in 1969 and it became available to the public in 1980. Its creator was basically inspired by three principles:
1. Everything is an object. Kay was inspired by the Logo language, created by Seymour Papert and his team in 1968 at MIT. In Logo there is only one object, which is the turtle. By sending messages to this object, different behaviors (movements) are obtained.
2. Leibniz's monadic and minimalist meta-principle: "To get everything from nothing, you only need to find one principle".
3. Plato's principle, expressed in Phaedrus: "Divide things into classes where the natural unions are, and do not try to break any part in the manner of a bad sculptor." Kay simplified or abbreviated this idea into "Divide nature into its unions."
These principles he developed into the following ideas as Smalltalk fundamentals:
1. Everything is an object.
2. Objects communicate through messages.
3. Objects have their own memory, which consists of other objects.
4. Every object is an instance of a class, which is also an object.
5. A class contains attributes and methods (procedures) that define the behavior of the objects of that class.
6. Classes are organized as a hierarchical tree and inherit methods and attributes from higher classes.
In the mid-1980s, OOP became the dominant programming paradigm. This paradigm was consolidated by the rise of graphical user interfaces (GUIs), for which OOP was especially suited.

Today there is a wide variety of programming languages that support object-orientation, and they can be divided into the following categories:
1. Pure OO languages, such as Smalltalk, Self, Ruby and Eiffel.
2. OO languages with procedural elements, such as Java, C#, VB.Net and Object Pascal.
3. Procedural languages extended to OO, such as Pascal, Perl, PHO and Matlab.
4. Languages of abstract data types, but without all the features of OO, such as Modula-2, CLU and JavaScript.
5. "Chameleon" languages that support multiple paradigms, such as Tcl.
Today, Java is the most widespread and widely used object-oriented language.

OOP vs. OOP (Data Oriented Programming)

In OOP, everything is an object, which integrates data (encapsulated) and code (the methods). In POD, everything is data: code and data have the same structure. This has the advantage of flexibility, since it allows to easily modify the code and to perform multiprogramming in general. In POD there is no encapsulation or polymorphism.

The most representative example is the Lisp language [Winston & Berthold, 1989], where data and code have the same structure: the list. Other examples of POD are the Awk and Sed languages [Dougherty, 1990].

MENTAL and the OOP
OOP - MENTAL comparisons

Classes and objects.
In MENTAL, classes are defined by generic expressions. Objects are instances of generic expressions with concrete arguments.
Objects vs. expressions.
In OOP everything is an object. In MENTAL, everything is an expression, where the distinction between data and processes is diluted because every expression is evaluated.
Messages vs. abstract space.
Communication between objects via messages is complex. Simpler is to use abstract space (memory) as a means of communication.
Data and code.
In OOP, data and code are integrated. In MENTAL In this sense, MENTAL can be considered a data-oriented language.are unified in the sense that both have the same structure.
Hierarchical inheritance vs. sharing.
MENTAL uses a more general and flexible concept than hierarchical (top-down) inheritance: sharing, which is expressed very simply by a generic expression. Sharing can be done with all kinds of expressions. This means more expressive and combinatorial freedom.
Polymorphism.
In OOP, semantics can vary depending on the arguments or the object receiving the message. In MENTAL, the components of the primitives can be of any type, but the semantics remain the same.
Events.
In OOP, events can occur before and after a message is sent. In MENTAL, events can occur before and after the evaluation of an expression.
Encapsulation.
In OOP there is encapsulation because data abstraction is used. In MENTAL there is no encapsulation, it is a transparent language. What is hidden are the implementations of the semantic primitives.
Universal paradigm.
MENTAL is a universal language that reflects a universal paradigm, a paradigm capable of expressing any particular programming paradigm based on abstractions, including objects.
Paradigm-language relationship.
In MENTAL there is a close and deep relationship between paradigm and language, between the universal paradigm and the universal language, since both reflect each other. On the other hand, the OOP paradigm is not directly reflected in the language, since each language interprets it differently.
Definitive paradigm.
OOP is not the "definitive paradigm", it is just one more paradigm and the most restrictive one. Objects is not the only way to see the world. MENTAL is the definitive paradigm, a paradigm based on 12 principles, degrees of freedom, dimensions or archetypes of consciousness. It assumes the primacy of consciousness, of the deep versus the superficial. The abstraction of objects is based on or inspired by the world of material objects. But the archetypes of the consciousness are at a deeper level and underlie the physical world (external) and the mental world (internal). Programming is a mental activity. The simplest and most straightforward way to program is to use the mental degrees of freedom or archetypes of consciousness.

Simple examples of sharing

⟨( f(x y) = (x+y x*y) )⟩ ⟨( g(x) = f(x 3) )⟩

A function (g) that depends on another (f) is defined.

g(7) // ev. f(7 3) ev. (7+3 7*3) ev. (10 21)
⟨( f(x) = (2*x + 1) )⟩ ⟨( g(x) = (3*x + 5) )⟩ ⟨( h(x) = (f(x) + g(x) + 7) )⟩

In this case, a function is defined through two functions.
(x = (3 5 7)) ( y = (a ⟨x⟩ b) // ev. (a (a (3 5 7 7) b) ev. (a 357 b) ( z = (a ⟨x⟩∪⟨x⟩ b) // ev. (a (a (3 5 7 7 3 5 7) b) ev. (a 357357 b)

In this case, the expression x is shared by y and by z. Changes in x immediately affect y and z.

(x = (1 2 3) y // ev. (a 123 b) z // ev. (a 123123 b)
(x = 123) (y = 456) ( z = (⟨x⟩ ⟨y⟩ ⟨x⟩+⟨y⟩) // ev. (123 456 579)

In this case, the expressions x and y are shared by z. Changes in x and/or y immediately affect z.

(x = 10) (y = 20) z // ev. (10 20 30)

Class example

We define a class X with which sets of integers can be created and modified, with the following methods:

Create a set C.
Add a number to a set C.
Remove a number n from a set C.
Replace a number n1 by another n2 of a set C.
Delete a set C.
Get the value of a set C.

The possible ways to invoke the class X are:

X/(CreateConj Name Value)
X/(AddNum Name n)
X/(RemoveNum Name n)
X/(ReplaceNum Name n1 n2)
X/(RemoveConj Name)
X/(ValueConj Name)

being:

n

n1

n2

n1

Specification:


  ⟨( X/p =


   (


(name = pp)


(value = pp\3)


( (pb>\1 = CreateConj) → 


         (name! = value)¡ )




( (p\1 = AddNum) → 


          (name! = {name↓ value})¡ )
 




( (p\1 = DeleteNum) → 


          (name! = name/(value=θ)¡ )




( (p\1 = SubstituteNum) → 


           (value2 = pb>\4)
           (name! = name/(value=value2)¡ )




( (p\1 = DeleteConj) → 


           ( (Name! = θ)¡ )




( (p\1 = ValueConj) → 


           ( (Name!)¡ )


    )                     


  )⟩

Examples:


X/(CreateConj A {1 2 3}) // A={1 2 3}



X/(CreateConj B {11 12 13}) // B={11 12 13}



X/(CreateConj C {21 22 23}) // C={21 22 23}



X/(AddNum A 9) // A={1 2 3 9}



X/(RemoveNum B 13) // B={11 12}



X/(ReplaceNum A 3 8) // A={1 2 8}



X/(DeleteConj C) // C=&θ



X/(ValueConj A) // ev. {1 2 3 9)         



X/(ConjValue B) // ev. {11 12}



X/(ValueConj C) // ev. θ

Bibliography

Alfonseca, Manuel; Alcalá, Alfonso. Programación Orientada a Objetos. Teoría y técnicas OOP para el desarrollo de software. Anaya Multimedia, 1992.
Booch, Grady. Object Oriented Design with Applications. The Benjamin/Cummings Publishing Co., 1991.
Bouzeghoub, Mokrane; Gardarin, Georges; Valduriez, Patrick. Objetos. Conceptos, Métodos, Herramientas. Eyrolles, Ediciones Gestión 2000, 1995.
Budd, Timothy. An Introduction to Object-Oriented Programming. Pearson, 2001.
Cox, Brad. Object Oriented Programming: An Evolutionay Approach. Addison Wesley, 1991.
Ceballos Sierra, Francisco Javier. Programación orientada a objetos con C++. Ra-Ma, 2003.
Dougherty, Dale. Sed & Awk. O’Reilly & Associates, Nov. 1990.
Joyanes Aguilar, Luis. Programación orientada a objetos. McGraw-Hill Interamericana de España, 1996.
Meyer, Bertrand. La nueva cultura del desarrollo del software. Systems, pp. 12-13, 10 Sept. 1990.
Winblad, Ann L.; Edwards, Samuel D.; King, David R. Software Orientado a Objetos. Addison-Wesley/Díaz de Santos, 1993.
Winston, Patrick; Horn, Berthold. Lisp. Pearson, 1989.
Wu, Thomas C. Introducción a la programación orientada a objetos con Java. McGraw-Hill Interamericana de España, 2001.

	MENTAL
	Main Menu
	Applications
	Computer Science
	Object Oriented Programming