Well, I guess most people know the answer already. Except that not everybody agrees on what it is, so a short tour of my perspective is in order.
The base idea behind objects is to define a record („struct“ in C terminology) together with the functions that operate on the fields.
In most if not all programming languages, this means that record and function definitions are placed in the same class construct.
Classes are usually modules as well: only a specific selection of members is accessible from the outside.
Typical terminology is object for the record, member variable for a record field (because it is a member of the object), and member function for a function (because it is a member of the class).
This kind of design is often referred to as object-based. A popular definition that I’m going to adhere to is that going from object-based to object-oriented means adding inheritance, or at least some kind of subtype relationship. However, it is interesting to see how useful object-baseness is even without subtypes, so object-orientation will have to wait for a little while.
Object-based design gives some nice synergies and benefits:
- Data that’s inside a single record tends to be closely related to each other and to the functions that work on it. In other words, classes usually make an excellent fine-grain module structure.
- Since code inside a class is supposed to work on objects of that class, it is a widely-adopted convention that, by default, every function has an object of that class as its first, implicit parameter:
- A function declaration of foo(SomeClass record)… can be written as foo().
- Inside the function’s body, the members can be accessed directly, so instead of record.blah = 5, people can write blah=5.
- Typical object-based code saves one parameter per function and one record. construct every third line or so, which greatly reduces clutter.
- The class construct imposes an easily recognizable structure on programs: All functions go near the data that they work with. There are other ways to achieve the same effect, of course, but in an object-based language, this structure is mandatory.
- There’s a slight drawback: parameter names and member variable names tend to clash, forcing awkward naming conventions (member = aMember) or constructs for explicit disambiguation (this.member = member).