Code projects have grown larger and larger in the last decades. For example, in the video, I already told you that the Microsoft code base consists of more than 50 million lines of code! I know this is a stupid measure for project size (puzzle: how to use exactly 50 millions of lines of code to print 50 million times "hello world" to the shell?). But, at least, it shows that there cannot be a single person who has read the whole code base.

One of the main questions for those massive code projects is: how to structure code in a way so that even tens of thousands of developers can happily work together on a common code project?

A robust answer to this question is "object-oriented programming". An object conceptually combines core functionality and data to build a cohesive whole. Most likely you have already heard the term "encapsulation": to bundle methods and data into a single, coherent object.

The big advantage of object orientation is its simplicity and intuitiveness (a fact that is often forgotten by many annoyed students of object orientation). Hence, you already know intuitively what an object is.

For example, let’s consider animals. Let's assume you want to build a virtual zoo with lots of different animals. Each animal will be a virtual representation in a giant computer program called "the zoo". From your perspective (as a programmer)---each animal is an object. It encapsulates many other objects that together built the unique virtual object in which is currently controlled by your unique virtual representation.

An animal consists of other objects: the liver (don’t ask me why this is the first one that came to my mind), eyes, legs, and many more. These concrete unique objects are your animal’s attributes. But each animal also has some dynamic attributes like the current speed, the age, or the intelligence level.

However, it would be very inefficient if each object in the vZoo was programmed separately by a programmer. There are myriads of different animals in the zoo. And each animal follows the same "programming recipe". For example, every animal object has a liver, legs, and an intelligence level. In object-oriented programming, you call these "programming recipes" "classes". In other words, classes are blueprints for generating objects (another term for objects is "instances"). The programmer starts coding by defining the class. Only then, they write code to programmatically create concrete objects that follow the blueprint. This way, you can easily create millions of animals in a simple for loop.

However, while each animal has an intelligence level, there are also subclasses of animals such as dogs, fishes, and snakes that each share some unique properties. For example, a snake can possess some poison (boolean value) and may have some unique sexual preferences. A fish can breathe underwater. And a dog is hairy and knows how to persuade humans.

We can create a class hierarchy by defining the subclass relationship between classes: every dog is an animal (with all their skills and properties) but not every animal is a dog (dogs have some unique skills and properties).

Let's summarize what you have learned today: programmers create classes that are blueprints for objects. Programmers create objects (also called instances) by following the recipe given by the class descriptions.