Today we're going to talk about object
oriented programming, it's one of the most
common ways that software is written
these days certainly for things like
applications on desktops and mobile
devices. The problem with object oriented programming
though is that it can be quite difficult
to get your head around at first 'cause it
uses so many different terms, you talk about objects sending messages to other objects, objects doing
things and you think "Well they're just bits of code, how are they doing anything?" and so on
so it can be difficult to get your head around it.
For Nicholas Wirth, who invented Pascal, once
described programs as being algorithms
plus data structures.  Now the data structures we can think of as the sort of the data that
our program's manipulating, whatever that might be.
And the algorithm - that's basically the
code they we're running to manipulate
that data.  One way we can think about this is thinking about something like a simple pong game,
sort of the very early computer games
you got back in the seventies.  Pong was
a very simple game that you played on
your TV.  It had - so that's your TV screen - you had
a little bat on this side which one
person controlled; you had another bat on
this side that another person controlled and then you had a ball which was a square
block.  These literally were square blocks that were filled in on the screen.
So one player could control this and move it up and down, and the other player could control this
to move it up and down, and the ball would bounce between effectively trying to be a sort
of tennis game.  The graphics were state of the art for the time, and you can still
find Pongs lying around mainly
museums.  There's one at the Computer History
Museum down in Cambridge if you were to go and play with it.  So the Pong game's very,
very simple but we can use it to sort of
think about how the probe would work and
so on and things.  So you've got two bats and a
ball.  So the data for this would be
relatively simple.  This paddle or
bat over here - you'd need to know where
it is, so you need its position; and we'll call that its y position.  And you'd probably keep track
of its x position as well just to make
it easier to draw things.  And you'd need
the same for this one over here and
again for the ball you'd need the ball's x pos.,
and the ball's y position.  So that's
the data that our program would
represent.  It doesn't need anything more than that really.  You'd perhaps have some representation
of screen but that'd be handled by the
computer, so we'll ignore that for now.
And we'd be able to write programs
which would use this data, manipulate it to run
the game.  So if a key was pressed, we would change the y position to make the bat go up;
or if a different key was pressed, we'd change this one's y position to make the
bat go down.  And we can change this to make
the ball sort of bounce off the edge of
the screen, so it looks like the ball's
moving around.  So we've got to write some code very
simply to do this.  So we could say something like,
if he - alright, so we've got to use Q to go up - is pressed then paddle 1 y pos equals paddle 1 y pos plus 1.
And we could do something similar for the going down for the same paddles -
we could write a basic program code that manipulate the variables to move the paddles around.
Then we can redraw the screen; and so we redraw the screen.  It looks like the
things are moving.  Actually all we've
done is change the variables' data and
then redraw the screen.  This is OK, and
for a simple program like this, this approach
would work and anything else would
perhaps be over the top.  But often you
would find that you'd have lots of data
that you'd want to group together.  So for
example with our pong game, we've got a variable to hold the x position; a variable to
hold the y position; a variable to
hold the ball's x position; a variable to
hold the ball's y position; and so on.
And we might actually say we're talking a lot of the
time about points on things.
So we actually want to group them together.  So we can
use in various programs that have the
facility to group things together as what we call a data structure.   And we can then refer to this
position either as a whole, so you can
set the position to be the same as
another position; or we can refer to the
individual things inside it.  So we can
pass it into a function, say, to draw the paddle, just passing the whole position in there;
but if you want to update one of the
values, we can just update that specific
value about the y position that we want to manipulate.  But there's still a slight issue with
this sort of approach.  It makes it easy to
refer to things and we could have lots of
these data structures referring to different things.  Rather than having separate
variables here, we could have a position
for paddle 1; and a position for paddle 2.
So we can refer to them and have lots of them.  We can have one data structure which we can then have
many different things for.  So we can actually group the data together, which is quite useful.
But the problem with all of this is that
the date is completely open and we can
write code anywhere in our program that
can manipulate it.  For a simple program like
Pong, having the data open is not a
problem.  Your program is probably not
gonna be more than a few hundred lines
long.  As the program grows, you're writing
something bigger, then you have lots of
files accessing the data and you might change some
things and forget to update part of the program.
So for example, you might update one
part of the program to only allow ten
entries rather the hundred and something, but the other part of the problem still
expects a hundred, and so it writes over the end, walks all over memory that's used for something else.
That's how you get a crash; your program won't work.  So, with object oriented programming we turn things on
their heads slightly.  Rather than thinking of the program in terms of the code we write and
how it modifies the data, we think rather
in terms of objects.  So, what would an
object be?  Well, using our Pong
example - the objects in this game would
be - well we've got two paddles in here; so we'd
have objects that would represent the
paddles; and we've got another object
here, which is the ball.  So we can sort of see what might be an object in a program.  But
the other thing we need to think about,
rather think about writing code that
manipulates the data, we need to think
about what these objects can do.  What
operations can we perform on them?
So for example, on our paddle, we might have operations which make it move up.  We might
have an operation that make it move down.
And that would be the same for
both paddles.  And we could ask the object to
perform that operation based on input from
the keyboard.  So the ball object would be
similar.  Rather having operations to
move it up to move it down, we just have
an operation says update your position.
We let the ball itself work out how
its going to move around the
screen.  The other thing we might have is
an operation to detect whether the ball
has collided with a paddle.  In this case,
we'd say to the ball, Have you collided with
this other object?  So we'd have the two
objects working together to work out
whether they've collided.  Now I've described
that and I've talked about objects
working with each other; objects having
operations.  How does this all fit down to
the way it works with a computer?  Well, to do that, we need to think about what an
object is.  And actually, an object is made up of three things. So let's look at the paddle
as an example to start with, and we'll think about the ball in a minute.  It's got some
state.  And that's things like its
x position and its y position.  But you
might also if you - taking this further - you might
have to be like the speed associated
with it as well.  And they'll just be
numerical values, perhaps integers,
floating point numbers, depending on the system
they're using.  There could also be other
objects, or we could build an object out of
other objects, but that's gonna be
advanced.  We'll look at that later on.
So what we've got here is no different from the
data structures we talked about earlier.
We've got some data and we've encapsulated
it together, and we can refer to it as a
whole.  The other thing that makes it
different is that we also have the
operations, and these are the things that
the object can do.  So if you think about our
paddle, we said it would be able to move up, and we said it would be able to move down.
We also said that you might be able to
draw it on the screen so we'd have a
draw operation as well.  We might have other operations that we need to make the program work,
but these aren't things that we're necessarily going to want do to the object like making it move up
or down.  So we might have to have operations in ours to get its position.  So we might have
a get position operation.  And that might be used, say, by the ball object we can
detect whether it's collided with it or not.  And it's having these operations which
makes a difference between a simple data structure and an object.  We think about
the state as being the center of the
object.  So we've got that state.  That's
our x position and our y position.  We'll keep it simple for now for the paddle.  When we think
about things in an object oriented way,
we say, No, there's a defined interface that can
manipulate this data.  And so you have
this sort of ring fence around the data.
So you've got this sort of move up operation, the move down, the draw operation and the
get position operation.  And the only way
this data here can be accessed or
manipulated by calling these operations.  And these create what we call the
interface to the object.  You can get its
position, which will give you an xy
coordinate.  We'll have more to have it return that.  You can draw it, and you'd perhaps have to give it
the screen you'd want it to be drawn on. You can get it to move down, and you can get it to move up.
and so we now write our programs
not in terms of manipulating the data,
but in terms of telling this object to
move up or to move down.  What actually
happens is that when the move up operation is
performed, there's a bit of code that we
specify here which updates the y
variable and then it returns back to
whatever called it to continue working.
So it's actually
a way of thinking about, and a way of
structuring, the program.
[Offscreen] Would it be fair to say that's a small program in its own right?
Yes; I mean, that's one way you could think about it.  The object is a small self-contained program
that's in its own right.  So it's got a
move up, and a move down, it can be drawn
and you get its position.  And then you write another self-contained program for the
ball, and that would perhaps have a similar state, but it would have different operations
associated with it.  So an object is actually made up of three things.  We've seen the state; we've
seen the operations; but the third thing
we have is actually not part of the
object as such.  But we also have identity.  And this is simply saying that we can
have many objects of the same type.  So we can have one paddle, like this; but we
can also - and I'll draw a smaller one for speed - we can also have another one with
its state and the operations around it.  And this can represent the other paddle.  So we've got
two objects with the identical interfaces:
one to represent the paddle on the left;
one to represent the paddle on the right.
So the only thing that can
alter the data is the operation on the object of a particular identity.  So if we wanted to access it,
we say to an object with this identity, perform this
operation; and that would then go and
modify the state of that object.
As I'm sure you've guessed we'd have
another type of object to represent the
ball, which should also have an x and a y position.  And it would have a different set of
operations around it.  So, some of them
might be similar.  Things like, we might have
a draw operation.  But we might have a collide operation instead, and then this time
update positions - that's really got an increase speed operation as well -
let's have a speed value in there.  The two objects that represent the paddle of the
same type.  They have the same state
associated with them, the same operations
associated with them.  But this one is of
a different type.  It's got different state -
it's got an xy position and speed, and it
also has a different set of operations
associated with it.  And of course it has its own identity, and if we wanted to, we could have two balls
in the game.  And generally, in most object oriented languages, when we write these things,
we define what we call a class, which is
basically the blueprint for building
objects that it specifies, what operations they have; and provides the
code for those operations.   Even though it acts on each individual object, it also
specifies how the data is stored and so on.  And then when we create an object, we
create a new one with its own identity,
with its own state, and then the operations
can perform on that individual object.
[Offscreen] If we come to update our program, you talked about how that can be a problem with structures.
[Offscreen] How's it easier here, then?
Because we've got this
defined interface for the object, the
rest of the program doesn't know
anything about how that object is
implemented.  So it doesn't need to know there's a y coordinate or an x coordinate in there.
All it needs to know is, to make it move up, it invokes the move-up operation on the object; or
invokes the move down to make it move down.  The beauty of this is you have lots of
different classes of objects that
implement this interface, and then you
can drop in whichever one you want.  So you could have a paddle which is wider, which
would just be different class of object,
and drop that in.  We could have perhaps a
specialist paddle which was two paddles that moved up and down in sync with each other.
And that'd just be a different class of object which you'd drop in inside.  And this is part of what we call
inheritance in object oriented
programming is one of the things which
can make it really powerful, which we'll look at in another video.
Over a long enough time scale, I think that human level artificial intelligence
is completely inevitable.
Um, if your auntie hangs around for long enough and continues to progress in what it can do...
