Object-oriented programming - Wikiwand

Imperative programming

Features from imperative and structured programming are present in OOP languages and are also found in non-OOP languages.

• Variables hold different data types like integers, strings, lists, and hash tables. Some data types are built-in while others result from combining variables using memory pointers.
• Procedures – also known as functions, methods, routines, or subroutines – take input, generate output, and work with data. Modern languages include structured programming constructs like loops and conditionals.

Support for modular programming lets programmers organize related procedures into files and modules. This makes programs easier to manage. Each modules has its own namespace, so items in one module will not conflict with items in another.

Object-oriented programming (OOP) was created to make code easier to reuse and maintain.^[29] However, it was not designed to clearly show the flow of a program's instructions—that was left to the compiler. As computers began using more parallel processing and multiple threads, it became more important to understand and control how instructions flow. This is difficult to do with OOP.^{[30][31][32][33]}

Objects

An object is a type of data structure that has two main parts: fields and methods. Fields may also be known as members, attributes, or properties, and hold information in the form of state variables. Methods are actions, subroutines, or procedures, defining the object's behavior in code. Objects are usually stored in memory, and in many programming languages, they work like pointers that link directly to a contiguous block containing the object instances's data.

Objects can contain other objects. This is called object composition. For example, an Employee object might have an Address object inside it, along with other information like "first_name" and "position". This type of structures shows "has-a" relationships, like "an employee has an address".

Some believe that OOP places too much focus on using objects rather than on algorithms and data structures.^[34][35] For example, programmer Rob Pike pointed out that OOP can make programmers think more about type hierarchy than composition.^[36] He has called object-oriented programming "the Roman numerals of computing".^[37] Rich Hickey, creator of Clojure, described OOP as overly simplistic, especially when it comes to representing real-world things that change over time.^[35] Alexander Stepanov said that OOP tries to fit everything into a single type, which can be limiting. He argued that sometimes we need multisorted algebras—families of interfaces that span multiple types, such as in generic programming. Stepanov also said that calling everything an "object" doesn't add much understanding.^[34]

Inheritance

Most OOP languages allow reusing and extending code through "inheritance". This inheritance can use either "classes" or "prototypes", which have some differences but use similar terms for ideas like "object" and "instance".

Dynamic dispatch

When a method is called on an object, the object itself—not outside code—decides which specific code to run. This process, called dynamic dispatch, usually happens at run time by checking a table linked to the object to find the correct method. In this context, a method call is also known as message passing, meaning the method name and its inputs are like a message sent to the object for it to act on. If the method choice depends on more than one type of object (such as other objects passed as parameters), it's called multiple dispatch.

Dynamic dispatch works together with inheritance: if an object doesn't have the requested method, it looks up to its parent class (delegation), and continues up the chain until it finds the method or reaches the top.

Data abstraction and encapsulation

Data abstraction is a way of organizing code so that only certain parts of the data are visible to related functions (data hiding). This helps prevent mistakes and makes the program easier to manage. Because data abstraction works well, many programming styles, like object-oriented programming and functional programming, use it as a key principle. Encapsulation is another important idea in programming. It means keeping the internal details of an object hidden from the outside code. This makes it easier to change how an object works on the inside without affecting other parts of the program, such as in code refactoring. Encapsulation also helps keep related code together (decoupling), making it easier for programmers to understand.

In object-oriented programming, objects act as a barrier between their internal workings and external code. Outside code can only interact with an object by calling specific public methods or variables. If a class only allows access to its data through methods and not directly, this is called information hiding. When designing a program, it's often recommended to keep data as hidden as possible. This means using local variables inside functions when possible, then private variables (which only the object can use), and finally public variables (which can be accessed by any part of the program) if necessary. Keeping data hidden helps prevent problems when changing the code later.^[49] Some programming languages, like Java, control information hiding by marking variables as private (hidden) or public (accessible).^[50] Other languages, like Python, rely on naming conventions, such as starting a private method's name with an underscore. Intermediate levels of access also exist, such as Java's protected keyword, (which allows access from the same class and its subclasses, but not objects of a different class), and the internal keyword in C#, Swift, and Kotlin, which restricts access to files within the same module.^[51]

Abstraction and information hiding are important concepts in programming, especially in object-oriented languages.^[52] Programs often create many copies of objects, and each one works independently. Supporters of this approach say it makes code easier to reuse and intuitively represents real-world situations.^[53] However, others argue that object-oriented programming does not enhance readability or modularity.^[54][55] Eric S. Raymond has written that object-oriented programming languages tend to encourage thickly layered programs that destroy transparency.^[56] Raymond compares this unfavourably to the approach taken with Unix and the C programming language.^[56]

One programming principle, called the "open/closed principle", says that classes and functions should be "open for extension, but closed for modification". Luca Cardelli has stated that OOP languages have "extremely poor modularity properties with respect to class extension and modification", and tend to be extremely complex.^[54] The latter point is reiterated by Joe Armstrong, the principal inventor of Erlang, who is quoted as saying:^[55]

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.

Leo Brodie says that information hiding can lead to copying the same code in multiple places (duplicating code),^[57] which goes against the don't repeat yourself rule of software development.^[58]

Polymorphism

Polymorphism is the use of one symbol to represent multiple different types.^[59] In object-oriented programming, polymorphism more specifically refers to subtyping or subtype polymorphism, where a function can work with a specific interface and thus manipulate entities of different classes in a uniform manner.^[60]

For example, imagine a program has two shapes: a circle and a square. Both come from a common class called "Shape." Each shape has its own way of drawing itself. With subtype polymorphism, the program doesn't need to know the type of each shape, and can simply call the "Draw" method for each shape. The programming language runtime will ensure the correct version of the "Draw" method runs for each shape. Because the details of each shape are handled inside their own classes, this makes the code simpler and more organized, enabling strong separation of concerns.

Open recursion

In object-oriented programming, objects have methods that can change or use the object's data. Many programming languages use a special word, like this or self, to refer to the current object. In languages that support open recursion, a method in an object can call other methods in the same object, including itself, using this special word. This allows a method in one class to call another method defined later in a subclass, a feature known as late binding.

Popularity and reception

Many popular programming languages, like C++, Java, and Python, use object-oriented programming. In the past, OOP was widely accepted,^[62] but recently, some programmers have criticized it and prefer functional programming instead.^[63] A study by Potok et al. found no major difference in productivity between OOP and other methods.^[64]

Paul Graham, a well-known computer scientist, believes big companies like OOP because it helps manage large teams of average programmers. He argues that OOP adds structure, making it harder for one person to make serious mistakes, but at the same time restrains smart programmers.^[65] Eric S. Raymond, a Unix programmer and open-source software advocate, argues that OOP is not the best way to write programs.^[56]

Richard Feldman says that, while OOP features helped some languages stay organized, their popularity comes from other reasons.^[66] Lawrence Krubner argues that OOP doesn't offer special advantages compared to other styles, like functional programming, and can make coding more complicated.^[67] Luca Cardelli says that OOP is slower and takes longer to compile than procedural programming.^[54]

OOP in dynamic languages

In recent years, object-oriented programming (OOP) has become very popular in dynamic programming languages. Some languages, like Python, PowerShell, Ruby and Groovy, were designed with OOP in mind. Others, like Perl, PHP, and ColdFusion, started as non-OOP languages but added OOP features later (starting with Perl 5, PHP 4, and ColdFusion version 6).

On the web, HTML, XHTML, and XML documents use the Document Object Model (DOM), which works with the JavaScript language. JavaScript is a well-known example of a prototype-based language. Instead of using classes like other OOP languages, JavaScript creates new objects by copying (or "cloning") existing ones. Another language that uses this method is Lua.

OOP in a network protocol

When computers communicate in a client-server system, they send messages to request services. For example, a simple message might include a length field (showing how big the message is), a code that identifies the type of message, and a data value. These messages can be designed as structured objects that both the client and server understand, so that each type of message corresponds to a class of objects in the client and server code. More complex messages might include structured objects as additional details. The client and server need to know how to serialize and deserialize these messages so they can be transmitted over the network, and map them to the appropriate object types. Both clients and servers can be thought of as complex object-oriented systems.

The Distributed Data Management Architecture (DDM) uses this idea by organizing objects into four levels:

1. Basic message details - Information like message length, type, and data.
2. Objects and collections - Similar to how objects work in Smalltalk, storing messages and their details.
3. Managers - Like file directories, these organize and store data, as well as provide memory and processing power. They are similar to IBM i Objects.
4. Clients and servers - These are full systems that include managers and handle security, directory services, and multitasking.

The first version of DDM defined distributed file services. Later, it was expanded to support databases through the Distributed Relational Database Architecture (DRDA).

Object patterns

The following are notable software design patterns for OOP objects.^[68]

• Function object: Class with one main method that acts like an anonymous function (in C++, the function operator, operator())

• Immutable object: does not change state after creation

• First-class object: can be used without restriction

• Container object: contains other objects

• Factory object: creates other objects

• Metaobject: Used to create other objects (similar to a class, but an object)

• Prototype object: a specialized metaobject that creates new objects by copying itself

• Singleton object: only instance of its class for the lifetime of the program

• Filter object: receives a stream of data as its input and transforms it into the object's output

A common anti-pattern is the God object, an object that knows or does too much.

Gang of Four design patterns

Design Patterns: Elements of Reusable Object-Oriented Software is a famous book published in 1994 by four authors: Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. People often call them the "Gang of Four". The book talks about the strengths and weaknesses of object-oriented programming and explains 23 common ways to solve programming problems.

These solutions, called "design patterns," are grouped into three types:

• 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
• Behavioral patterns (11): Chain-of-responsibility pattern, Command pattern, Interpreter pattern, Iterator pattern, Mediator pattern, Memento pattern, Observer pattern, State pattern, Strategy pattern, Template method pattern, Visitor pattern

Object-orientation and databases

Both object-oriented programming and relational database management systems (RDBMSs) are widely used in software today. However, relational databases don't store objects directly, which creates a challenge when using them together. This issue is called object-relational impedance mismatch.

To solve this problem, developers use different methods, but none of them are perfect.^[69] One of the most common solutions is object-relational mapping (ORM), which helps connect object-oriented programs to relational databases. Examples of ORM tools include Visual FoxPro, Java Data Objects, and Ruby on Rails ActiveRecord.

Some databases, called object databases, are designed to work with object-oriented programming. However, they have not been as popular or successful as relational databases.

Date and Darwen have proposed a theoretical foundation that uses OOP as a kind of customizable type system to support RDBMSs, but it forbids objects containing pointers to other objects.^[70]

Responsibility- vs. data-driven design

In responsibility-driven design, classes are built around what they need to do and the information they share, in the form of a contract. This is different from data-driven design, where classes are built based on the data they need to store. According to Wirfs-Brock and Wilkerson, the originators of responsibility-driven design, responsibility-driven design is the better approach.^[71]

SOLID and GRASP guidelines

SOLID is a set of five rules for designing good software, created by Michael Feathers:

• Single responsibility principle: A class should have only one reason to change.
• Open/closed principle: Software entities should be open for extension, but closed for modification.
• Liskov substitution principle: Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.
• Interface segregation principle: Clients should not be forced to depend upon interfaces that they do not use.
• Dependency inversion principle: Depend upon abstractions, not concretes.

GRASP (General Responsibility Assignment Software Patterns) is another set of software design rules, created by Craig Larman, that helps developers assign responsibilities to different parts of a program:^[72]

• Creator Principle: allows classes create objects they closely use.
• Information Expert Principle: assigns tasks to classes with the needed information.
• Low Coupling Principle: reduces class dependencies to improve flexibility and maintainability.

• High Cohesion Principle: designing classes with a single, focused responsibility.
• Controller Principle: assigns system operations to separate classes that manage flow and interactions.
• Polymorphism: allows different classes to be used through a common interface, promoting flexibility and reuse.
• Pure Fabrication Principle: create helper classes to improve design, boost cohesion, and reduce coupling.

Systems

• CADES
• Common Object Request Broker Architecture (CORBA)
• Distributed Component Object Model
• Jeroo

Modeling languages

• IDEF4
• Interface description language
• UML