So, if you're new to programming, or just hang around people that are programmers, you may have heard of things called "objects".
In this article, we will discuss what exactly objects are, and what they are like in certain languages.
What is an object?
At its most fundamental level, an object is a collection of data grouped together.
Here's a classic example, a Person object.
Say we want to talk about a person in some code, people in the real world are more complex than a simple number, or a string of text (text, as the kind you're reading now, in programming is referred to as a "string").
But, combining those last two, we get two basic properties all people have in common, name and age.
So, we know all people have a name and an age, but how do we represent that?
Well, not writing in any particular language, an object may be represented like following:
{
String name;
Number age;
}
This says that this object (o) contains some string data called name and some number data called age.
(The semicolons ; just separate the lines, like decoration.)
The idea of an object in programming is no different than the idea of having a subscript i on a variable V (Vi) in science (which stands for the "Initial Velocity" of a real-world object).
Disambiguating "class" and "object".
If you've heard "object", you've likely also heard of "class".
If you haven't, you can skip this, as it may just add confusion for the time-being.
So, what is a class?
A "class" is a general programming term that refers to the structure of an object.
In fact, most people compare classes to blueprints, where the class is the blueprint and the object is the building (finished product).
Classes in most programming languages are defined like so:
Person {
String name;
Number age;
}
This states there exists a class called Person, whose members consist of a name "field" and an age "field", where a "field" is some named data.
But, classes are comprised of more than just the blueprint.
Because in the real world, we actually use those plans to build something. - In programming, it's not much different.
The "building" we make with this "blueprint" class is called an "instance", as in "I have an instance of a class.".
Any building constructed with the Person blueprint will always be a Person instance (but not always vice-versa; kind of like how all squares are rectangles, but not all rectangles are squares).
What objects look like in multiple languages.
Now that we know what an object and a class is, lets see how they look in various languages, in order of difficulty from easiest to understand to hardest to understand.
In case you were thinking of dipping your toes into the water a little.
To help boost your understanding a little, all "people" (Person instances) created will have the name "Tom" and will be fifteen (15) years old.
In other words, the same thing will be shown, just in a bunch of different programming languages.
Python.
Python has simple object-classes that anyone can read!
class Person:
def __init__(self, name, age):
self.name = name
self.age = age
name = ""
age = 0
person = Person("Tom", 15)
JavaScript.
JavaScript allows you to create objects on their own, or from a blueprint.
person = {
name: "Tom",
age: 15
};
class Person {
constructor(name, age) {
this.name = name;
this.age = age;
}
}
person = new Person("Tom", 15);
// Does the same thing as the last definition.
Java.
Java has classes but not raw objects, unlike JavaScript.
class Person {
public Person(String name, int age) {
this.name = name;
this.age = age;
}
public String name;
public int age;
}
/* ... */
Person p = new Person("Tom", 15);
C.
C is one of the barest languages to exist, but it still provides us with a neat way to organize our data!
struct Person {
char* const name;
int age;
};
/* ... */
struct Person p = {
name: "Tom",
age: 15
};
POST-SCRIPT UPDATE.
Technically I wasn't actually describing "objects" in this article. As DarkWiiPlayer pointed out.
A structure is only a piece of an object's identity.
The other part is "methods", functions that are linked to the object, and can read and/or write its properties.
Thanks for reading!
Cheers!
Cheers!
Top comments (4)
The first statement, and you're already leaving out 50% of the magic
A collection of data on its own is not an object. It's an array, a map, or a struct (or record, if you come from pascal).
What makes it an object is the combination of data and behaviour, aka. methods.
This also shows in your examples: you're bulding a bunch of objects, but you're not giving them any methods. In a strictly OO sense, these objects are completely useless, as the only meaningful way of interacting with them is directly reading and setting their attributes, which you're not supposed to do (tell-don't-ask principle)
Usually yes, but in dynamic languages, with enough metaprogramming you can often still mess up an object to the point where it's arguable whether it still belongs to its class. In languages like Lua, where classes aren't a language feature but can still be implemented easily through metaprogramming, it is absolutely possible to completely override anything a constructor did and effectively "change" the class of an object.
C doesn't have classes or objects as a language feature. You can kind of simulate them by combining structs and function pointers, but this is still very rudimentary and doesn't let you use classes at all.
That's just how I see an object, at minimum.
You make a good point that I don't make objects seem discriminable from arrays or maps (though a map is more or less an object around saving k/v).
I tried to coach the idea that objects aren't arrays (because object fields use names and not numbers).
But, maybe this can be covered in a future issue.
Yes; but, put bluntly, that's wrong. What you think of an object is really just a struct.
If you look at wikipedia, you'll get two definitions of what an object is. There's a very generic one:
which you'll often see outside the context of OOP, and there's a more specific definition on the article on object-oriented programming that states:
Even a taco is an object.
PS Happy New Year