WEBVTT

00:00:00.440 --> 00:00:02.600 align:middle
Hello. In the previous session,

00:00:02.760 --> 00:00:06.880 align:middle
we saw how to implement
the Booleans: not and or.

00:00:07.040 --> 00:00:11.960 align:middle
The third question remains:
why on earth did we ask these questions?

00:00:12.120 --> 00:00:13.880 align:middle
That's what we will study.

00:00:14.760 --> 00:00:20.120 align:middle
Let's review the implementation.
For not, there were two objects.

00:00:20.280 --> 00:00:22.400 align:middle
We had true and false.

00:00:22.560 --> 00:00:25.440 align:middle
They were instances
of the classes True and False.

00:00:25.600 --> 00:00:27.200 align:middle
When we sent a message not,

00:00:27.360 --> 00:00:31.640 align:middle
we queried their respective classes
and we executed the methods.

00:00:32.560 --> 00:00:34.080 align:middle
So no problems here.

00:00:35.120 --> 00:00:37.240 align:middle
As I said,

00:00:37.400 --> 00:00:39.720 align:middle
if you look at what you're doing:

00:00:39.880 --> 00:00:42.920 align:middle
first, let the receiver decide.

00:00:43.080 --> 00:00:46.080 align:middle
It means you don't take any decisions,

00:00:46.240 --> 00:00:49.320 align:middle
but you send a message
which will resolve itself.

00:00:49.480 --> 00:00:53.840 align:middle
So these two heuristic functions were:
let the receiver decide;

00:00:54.000 --> 00:00:57.320 align:middle
and do not ask but tell to do things.

00:00:57.480 --> 00:00:58.960 align:middle
I'll mention this again.

00:00:59.120 --> 00:01:02.480 align:middle
Now let's look at the exercise itself.

00:01:03.080 --> 00:01:04.720 align:middle
So what's this all about?

00:01:04.880 --> 00:01:08.240 align:middle
You will never implement Booleans
in your life,

00:01:08.400 --> 00:01:10.080 align:middle
at least I hope so.

00:01:10.240 --> 00:01:13.000 align:middle
Is it really totally useless?

00:01:13.160 --> 00:01:15.920 align:middle
What are the underlying lessons?

00:01:16.080 --> 00:01:19.240 align:middle
I think it's very important
to ask you this question:

00:01:19.400 --> 00:01:23.600 align:middle
yes, the implementation is like that,
but then what's this all about?

00:01:24.560 --> 00:01:29.360 align:middle
In fact, it shows
that whenever I use message sends,

00:01:29.520 --> 00:01:33.640 align:middle
whenever I send a message,
I have some sort of case statement.

00:01:35.000 --> 00:01:38.800 align:middle
You will also find these
in C programming, etc.

00:01:39.880 --> 00:01:42.840 align:middle
Sending a message
is about multiple choices.

00:01:44.160 --> 00:01:46.880 align:middle
What's interesting is:
when you send a message,

00:01:47.040 --> 00:01:50.720 align:middle
in the end, it's more than a case
because it's a dynamic case.

00:01:50.880 --> 00:01:54.960 align:middle
In fact, it depends on the loaded
classes and on the created instances.

00:01:55.720 --> 00:01:58.640 align:middle
Actually, when you program in Java,

00:01:58.800 --> 00:02:02.040 align:middle
you would often write x.f()

00:02:02.200 --> 00:02:04.080 align:middle
to invoke the method f.

00:02:04.240 --> 00:02:07.240 align:middle
What I am explaining to you now is:
this period

00:02:08.000 --> 00:02:09.560 align:middle
is a choice operator.

00:02:10.840 --> 00:02:12.600 align:middle
It's really crucial

00:02:13.400 --> 00:02:15.360 align:middle
that this choice is dynamic.

00:02:15.520 --> 00:02:17.800 align:middle
We didn't often tell you about it,

00:02:17.960 --> 00:02:22.960 align:middle
but this is actually
what is strongly exemplified here.

00:02:23.120 --> 00:02:25.840 align:middle
To summarize, when you send a message,

00:02:26.000 --> 00:02:29.360 align:middle
it really functions
like a dynamic case statement

00:02:29.520 --> 00:02:33.120 align:middle
in the sense that it depends
on the loaded classes.

00:02:33.280 --> 00:02:36.440 align:middle
This Boolean example
has two instances and two classes;

00:02:36.600 --> 00:02:39.600 align:middle
even with 50 of them,
it'd work the same way.

00:02:40.320 --> 00:02:43.920 align:middle
Whenever you send a message
to the virtual machine

00:02:44.080 --> 00:02:47.400 align:middle
- since Pharo has one
like Java or C# -

00:02:47.560 --> 00:02:50.520 align:middle
the virtual machine's execution tool

00:02:50.680 --> 00:02:54.400 align:middle
selects the right method
depending on the receiver's class.

00:02:54.560 --> 00:02:58.160 align:middle
So sending a message
is a choice operator.

00:02:58.320 --> 00:03:00.520 align:middle
And each time you use a condition,

00:03:00.680 --> 00:03:04.360 align:middle
you replace this process

00:03:04.520 --> 00:03:07.920 align:middle
implemented in the choice-making
virtual machine.

00:03:08.800 --> 00:03:11.400 align:middle
So the solutions with not show

00:03:11.560 --> 00:03:13.560 align:middle
that you should use the choice

00:03:13.720 --> 00:03:17.240 align:middle
given by the virtual machine
to implement programs.

00:03:17.400 --> 00:03:19.720 align:middle
You don't need to use any ifs

00:03:19.880 --> 00:03:24.240 align:middle
because sending a message means
an if or a condition.

00:03:24.400 --> 00:03:26.920 align:middle
The question you might ask now:

00:03:27.080 --> 00:03:31.160 align:middle
what if I had expressed the initial
exercise in a totally different way?

00:03:31.320 --> 00:03:35.160 align:middle
What if I had said, "Can you implement
Not in the Boolean class,

00:03:35.320 --> 00:03:37.000 align:middle
or Or in the Boolean class?"

00:03:37.160 --> 00:03:39.400 align:middle
This solution wouldn't have worked.

00:03:40.200 --> 00:03:42.720 align:middle
That's strange.
What does it mean?

00:03:42.880 --> 00:03:45.680 align:middle
Having one or several classes
greatly impacts

00:03:45.840 --> 00:03:48.400 align:middle
the way I design my applications.

00:03:49.120 --> 00:03:50.120 align:middle
Indeed,

00:03:51.440 --> 00:03:56.560 align:middle
classes play the role
of branches or choices.

00:03:56.720 --> 00:03:59.080 align:middle
So if you have a choice
to choose yogurt,

00:03:59.240 --> 00:04:03.200 align:middle
but there's only one pot in the shop,
you will choose this yogurt.

00:04:03.360 --> 00:04:04.400 align:middle
It's the same.

00:04:04.560 --> 00:04:06.520 align:middle
It means your class represents

00:04:07.520 --> 00:04:09.440 align:middle
a case in your inheritance tree.

00:04:09.600 --> 00:04:10.880 align:middle
What does it imply?

00:04:11.040 --> 00:04:14.040 align:middle
It implies that when I look at a design

00:04:14.200 --> 00:04:17.160 align:middle
with a big fat class full of methods,

00:04:17.320 --> 00:04:20.920 align:middle
I could express it
as a hierarchy instead.

00:04:21.080 --> 00:04:25.280 align:middle
This design is better
because it's more modular.

00:04:25.440 --> 00:04:29.680 align:middle
I can easily
add another choice if I want.

00:04:29.840 --> 00:04:32.760 align:middle
I can extend a choice and say:
"This wasn't bad.

00:04:32.920 --> 00:04:35.960 align:middle
"I can refine it to have a new one."

00:04:36.120 --> 00:04:38.880 align:middle
Moreover, it can reduce complexity:

00:04:39.040 --> 00:04:43.840 align:middle
I can focus only on one class, not
on something with so many conditions.

00:04:44.800 --> 00:04:49.000 align:middle
So on the one hand,
we have a choice operator;

00:04:49.160 --> 00:04:52.640 align:middle
and on the other hand,
something that expresses choices.

00:04:52.800 --> 00:04:57.640 align:middle
When you put them together,
you get good-quality OOP.

00:04:57.800 --> 00:05:00.040 align:middle
What's even better

00:05:00.200 --> 00:05:03.520 align:middle
is that when you look
at the solution with hierarchies,

00:05:03.680 --> 00:05:07.120 align:middle
it becomes even better
because I can package the solutions.

00:05:07.280 --> 00:05:11.480 align:middle
It means I can package this as core,
and that this is a plug-in.

00:05:11.640 --> 00:05:14.640 align:middle
I will tell my client,
"If you want this feature,

00:05:14.800 --> 00:05:17.720 align:middle
"you just need to download this plug-in
and pay me."

00:05:17.880 --> 00:05:20.360 align:middle
I will load this code dynamically.

00:05:20.520 --> 00:05:23.760 align:middle
When I create an instance of this class,

00:05:25.400 --> 00:05:27.840 align:middle
when I send my message Operation here,

00:05:28.520 --> 00:05:31.840 align:middle
the plug-in's code will be executed
in the system.

00:05:32.000 --> 00:05:36.440 align:middle
To us, that's the essence of OOP.

00:05:36.600 --> 00:05:40.120 align:middle
I send a message
and will select the right method.

00:05:40.960 --> 00:05:45.040 align:middle
And I will use the fact that I know
the system selects the right method

00:05:45.200 --> 00:05:47.960 align:middle
to get even more elegant
implementations.

00:05:48.120 --> 00:05:50.320 align:middle
What have we learned?

00:05:50.480 --> 00:05:55.040 align:middle
We've learned that sending a message
lets the receiver decide and choose.

00:05:55.200 --> 00:05:58.400 align:middle
Client does not have to decide.

00:05:58.560 --> 00:06:00.760 align:middle
Client code is more declarative.

00:06:00.920 --> 00:06:04.800 align:middle
There are no conditions. I give orders:
do this, do that, open, close;

00:06:04.960 --> 00:06:09.280 align:middle
not, "Do you belong to this class?
Are you ready to be closed?"

00:06:09.440 --> 00:06:12.520 align:middle
Different receivers
may be substituted dynamically.

00:06:12.680 --> 00:06:15.840 align:middle
We will see about this later,
but it's implied.

00:06:16.560 --> 00:06:20.240 align:middle
So most of the time,
try to avoid writing ifs.

00:06:21.240 --> 00:06:23.560 align:middle
Use objects and messages when you can.

00:06:23.720 --> 00:06:27.760 align:middle
It's not always the case,
but use them at least when you can.

00:06:29.280 --> 00:06:31.880 align:middle
The execution engine,
the virtual machine,

00:06:32.040 --> 00:06:37.120 align:middle
acts as a conditional switch
each time you send a message.

00:06:37.680 --> 00:06:39.000 align:middle
So use it.

00:06:39.160 --> 00:06:41.960 align:middle
You can also have fun
typing the AntiifCampaign.

00:06:42.120 --> 00:06:46.800 align:middle
Programmers launched this campaign
to make people stop writing ifs.

00:06:48.760 --> 00:06:50.960 align:middle
So what have we learned in this session?

00:06:51.120 --> 00:06:53.280 align:middle
Two things: when I write x.f(),

00:06:53.440 --> 00:06:57.720 align:middle
either in Java or in Pharo,

00:06:58.600 --> 00:07:02.400 align:middle
I make a choice:
I choose the method f

00:07:02.560 --> 00:07:06.080 align:middle
that must be executed
depending on the receiver.

00:07:06.840 --> 00:07:08.640 align:middle
So I have this choice operator

00:07:08.800 --> 00:07:12.000 align:middle
and a hierarchy
which represents potential choices.

00:07:12.160 --> 00:07:16.560 align:middle
So it's really a skeleton
thanks to which choices can be made.

00:07:16.720 --> 00:07:20.800 align:middle
As a result, I have no conditionals.
and more extensible programs.

00:07:21.800 --> 00:07:24.480 align:middle
This is the end of the first session

00:07:24.640 --> 00:07:27.160 align:middle
about object designs in Pharo.

00:07:28.160 --> 00:07:30.520 align:middle
And we will see more
in the next sessions.