-In this lecture, I want to discuss methods and messages,
and their differences.
A method is a named sequence of instructions.
I defined a method that is "makeCrepes", and it is like a recipe:
you take eggs, you put milk, flour and sugar,
and then, you get crepes out of that.
So, a method is really a named sequence of instructions
that will be executed in reaction to a message.
So, what we see is that all the instances of a class
share the same behavior
because this behavior is defined as a method in a class.
So, when I send a message to an instance of the class Rectangle
when I send the message "area", for example,
I will look for the method in the class of the receiver,
so in the class Rectangle.
And then, I will apply this definition, this method on the receiver.
And then, the method will use the specific data
of the instance that receive the message.
And that is why the methods are shared among all the instances of a class.
So, if we step back, a method has a name.
It defines a procedure,
how to define a process and a computation.
In addition, it accesses the private data of the object.
This is really important.
Compared to a message,
a method has access to the private data of the object.
It will either use it for the computation or modify it.
So, if we check, on the one hand,
we have messages, that look like orders.
So, we declare what we want the object to do.
And on the other hand, methods,
that are how the object should perform the computation
in reaction to the message.
What you see is that the message is not aware
of the external structure of the object.
In fact, this is not really important
for the client that sends a message to an object.
And methods, on the other side, have access to the object's data.
In addition,
methods are looked up dynamically, depending on the class of the receiver.
Here are two examples to illustrate this point.
One that we already saw in the previous lecture.
Imagine that we have cats, dogs and fish.
When I send a message to a cat, I will look in the class "cat",
and I will apply the behavior that is associated with the method
to the instance "cat".
So, all the instances of the class "cat" share the same behavior,
but this behavior is different from the one of the dog.
And this is the same for shapes.
You can imagine that you have geometrical shapes
like rectangles, circles and squares,
and that you want to compute the area of one of those.
Here, when I send the message "area" to a circle,
I want to have the computation based on circles
to be executed on my instance.
And this is what the late binding is doing.
This means that I will look in the class of the receiver
to find the corresponding methods.
Now, what is more important is that I can have a list of shapes
and I do not have to check upfront whether it is a rectangle or a square.
What I can do, if I have a figure composed of multiple shapes,
and if I want to know the total area of the diagram,
I can just sum up really fast
by sending the message "area" to all the shapes.
As a client, I do not have to distinguish between them.
I will just send the message "area",
which will then be dispatched to the class.
This means that if you have two rectangles and a circle,
then, I will execute twice the method "rectangle area" for the rectangles
and once the method "area" for the circle.
This is late binding.
Late binding is the notion
that as a client,
I do not have to know
the type or the class of the receiver.
I just have to declare that I want to do an action.
And then, the system, dynamically,
will find the corresponding method and execute it for each receiver.
And that is really powerful.
The term "late binding"
means that at compilation time,
we do not know exactly what code will be executed.
It will be selected during execution of the program.
And this is super powerful
because it means that I can potentially load code,
I can create objects on the fly,
and based on these creations, their behavior will be executed.
This is something that you do not know at compilation time,
when you write your program.
But when the program is executed, the correct method will be found.
Now, I want to stress something.
We have this vision of the object where the data is private.
The methods can access this private data. The messages do not really care.
They just talk to the object,
and then, the methods will execute and access the data.
This is an important property which is called "encapsulation".
What is data encapsulation?
From the client's point of view, the details are hidden from me.
And this is important because it means
that I can have two different implementations
of the same functionality
and that I do not care if they change as soon as I get the same.
Here is an example with two different ways to compute area.
Imagine that you have two different classes of rectangles,
with one that is optimized and one that is not optimized,
for example.
Then, as a client, it does not matter to me.
The only thing I want is when I send the message "area"
to one of the rectangles, I get the correct answer.
The way it is implemented is not my concern.
This is the concern of the methods.
This means that object encapsulation is really important,
because with late binding,
it means that my program can evolve over time.
I can substitute an object with another one
that fulfills the same API, that offers the same responsibility,
but that can do it in a different way.
This means that this way, I can build modular systems.
From that perspective, late binding and object encapsulation
are really powerful because they support the evolution of systems.
In summary, what you should remember is that on the one hand,
we have messages that are sent to objects,
that are abstract, they are orders.
And on the other hand, you have methods,
that are sequences of instructions that are executed
and can have access to the data of the object,
and that take care of the details.
Then, in addition, late binding will select the correct methods
when we send a message.
This means that I can have multiple objects
with the same API or interface that will reply to the same message,
that can be mixed together.
And me, as a client, I do not have to worry about that.
I do not have to check if this the correct object.
You send a message and the system will automatically select
the correct method for you.
It means that, from that perspective,
your object will be able to evolve over time
and you will have a more modular system.