Hi, welcome to this new lesson. We are going to continue talking about classes and how to really structure our files and how we can actually work
with multiple files, especially when we start
thinking of classes. Classes are very modular or something that makes
sense to almost package and have completely independent from the way we instantiate
classes in a particular code. Really thinking
of classes almost as libraries or
objects that we might deploy in our projects
at different times. Starts to reveal a little bit more of their modularity and a little bit more the way in which we can deploy their
power in a way. Let's just jump into the
code and discuss what actually we can do to
organize a class structure. Let's just remember
where we left off. We have this grading rectangle. This is a class that is
starting to get a bit long. I've used this series of dashes, this comment line to separate somehow the areas of
the code that refer to the class from something that could be the actual
implementation of the code, what we have been writing prior. Let's see how we
could actually open up a new tab here in processing. If we do here a new tab, and we could call it
a gradient rectangle. You see this new tap here, it's going to be a new area or a new
piece of code for us, and we're going to start
thinking of this area of code as dependency or something that
complements our code. Let's just take all the
code from these comments. Everything that has
to do with the class, we're going to cut it, and we're going to paste
it in this second tab. We're going to start
organizing our code. At this point, we
can actually get rid of these comments because
they're actually serving the purpose of the separation actually comes from
this different file. Let's just bring this back
and this is starting to look a lot more like a piece of code that we had created
without a class. But it makes use somewhere here of the
grading rectangle class. Let's see if we try to run this, we are not able to run that. Well, let's see how we could
actually access and import the information from the
gradient rectangle class. Let's do import and let's
use the name of the class. That was defined as and
we can actually give it a name as we could call it
GR, gradiate rectangle. The class name could be long, but if we want to actually
give it a different name here, we can import that with
a different name or we can actually just
keep it like that. Let's see, at this point, I'm going to give
you the name GR. Now, every time that I use
the gradient rectangle, call, I'm going to have to say
from the grading re art, gradient rectangle script, which is actually a different
script altogether. Use that class. That class belongs to
a different space. Belongs to a different script
that we are importing. Here, you see we could actually have everything
that we had before. But we're actually starting
to separate our files. If you really look at this tab, this tab here says the name
of the class dot Pi or PY, which stands for a Python file. This is actually
if you look into the folder where this
script is actually saved, you will see that you
have a class script. This is what we talk about
the boundaries of the class. The encapsulation of
the information of the class is a
self-contained object, and this self-contained
object could be used in multiple scripts. But basically, the class
might not need to change. This is, in fact, when you start really realizing how processing is
already written. Many of the functions,
for instance, the random attribute, we have been already
importing something. It's an inbuilt class that
is being provided for us. Similarly, a vector class
is being a class all along. They have been
objects that we have been using and deploying
within the code, and really if we try to
understand what they are, how they were constructed
in the first place, they were actually conceived as a class structure that
we are importing, and we don't need
to see that code necessarily because
processing already has its dependency to
the actual source. We are basically doing exactly the same thing
with our own class. We're inventing a class
called a gradient rectangle. We are importing it
into our system, and we can actually deploy it. This is a great power of
having multiple files. You can actually go ahead and construct an infinite
number of classes, and those could actually
be brought into your code. Without needing to have
a really long code that might be difficult to read. I really recommend you
to really start breaking your classes into different
very readable chunks. The final thing that I
would like to do as well is that sometimes whenever you have a class such as this one, that you think, well, I always want to be calling these three functions together, the calculate gradient,
the display, the move. Sometimes you will see this operation where you
have a function called run. That in itself invokes the self-dot calculate gradient, self-display, and self-dot move. This function is kind of
like a shortcut function. In case you want to
call this one instead. If we go back now
to our main class, you remember that we're calling these three functions every time we can save
that by saying run. Execute your internal
functionality and you'll see we
get the same result. But again, when you're operating
from within the class, you might want to specify
a series of behaviors, that compound to one single
functionality and this is a pattern that you
might see quite a bit where you could
actually decide, oh, this particular behavior,
it's really useful for us to be able to have an outline almost this run function becomes an outline of the
behaviors of this class. You'll see in future
sessions that we are going to spend a lot of
time in this outline. Because each function, could be thought in itself
as a contribution to a more complex behavior, and the outline of a class would really dictate
its expressivity, like the way it displays
itself in the screen. Mostly the call of that class is just a very simple call
for that class to exist, but we're actually going
to spend a lot of time in the outlining of the
behavior of the class. We're starting to get into what is object-oriented
thinking, how do we organize our
code so that we actually have a standalone class
that is very modular, and it's something that we
can reuse in many ways. How do we organize the code within a class
so that we can actually control its behavior
and really tinker and iterate over the results that
we're seeing on the screen. I'll invite you to use
this methodology for your design work
because it really maintains a very
structured organization of your code and as your code starts getting
longer and longer, you might want to have a
way of finding and really isolating the pieces that actually have the biggest
impact into your design. I hope that's helpful, and I'll see you in
the next session.