OOP is a programming paradigm that first surfaced in the 1960s, but didn't gain traction until the 1980s with C++. Its core idea is that programs should be composed of individual entities, or objects, each of which has the ability to communicate with other objects around it by passing messages. Additionally, each object may have the facility to store data internally (called state).
Objects in an OOP application are often modeled on real-world objects, so even non-programmers usually recognize the basic role that an object plays. And, just like the real world, OOP defines objects and classes with similar characteristics belonging to the same classes and objects. A class is a construct for defining properties for objects that are alike and equipping them with functionality. For example, a class named Car might define the attributes color and mileage for its objects, and assign them functionality: actions such as open the trunk, start the engine, and change gears. These different actions are known as methods, although you'll often see Rails enthusiasts refer to the methods of a controller (a kind of object used in Rails with which you'll become very familiar) as actions; you can safely consider the two terms to be interchangeable.
Understanding the relationship between a class and its objects is integral to understanding how OOP works. For instance, one object can invoke functionality on another object, and can do so without affecting other objects of the same class. So, if one car object was instructed to open its trunk, its trunk would open, but the trunk of other cars would remain closed—think of KITT, the talking car from the television show Knight Rider, if it helps with the metaphor. Similarly, if our high-tech talking car were instructed to change color to red, it would do so, but other cars would not.
When we create a new object in OOP, we base it on an existing class. The process of creating new objects from a class is called instantiation.
As I've mentioned, objects can communicate with each other via messages, invoking functionality (methods) on other objects. Invoking an object's methods can be thought of as asking the object a question and getting an answer in return. Consider the example of our famous talking car again. Let's say we ask the talking car object to report its current mileage. This question is not ambiguous: the answer that the object gives is called a return value.
In some cases, the question-and-answer analogy seems ill-fitting. In these situations, we might rephrase the analogy to consider the question to be an instruction, and the answer a status report indicating whether or not the instruction was executed successfully.
Sometimes we need more flexibility with our instructions. For example, if we wanted to tell our car to change gear, we tell it not only to change gear, but also which gear to change to. The process of asking these kinds of questions is referred to as passing an argument to the method. An argument (also called a "parameter") is an input value that's provided to a method. An argument can be used to influence: how a method operates on which object a method operates. As one might expect, the object sending the message is called the sender, and the object receiving the message is called the receiver.