[music] Having now seen multiple inheritance and Ruby style mixins, there's
a third comparison we need which are, is with interfaces as you see in languages
like Java and C#. This is an important distinction, even
thought interfaces are really about static typingand Ruby doesn't have static typing.
But Ruby also doesn't have multiple inheritance.
We can learn concepts even if we're not using a language that happens to have that
concept. So since interfaces really don't make
sense in Ruby, I will use Java code in this segment but I'll explain what's going
on and, and it shouldn't be any trouble even if you haven't seen Java before.
But we do need to take a step back and say, wait a minute, static typing, we've
only seen that for ML. What is static typing mean for object
oriented programming? Well it turns out what we're typically
trying to prevent is a method missing error.
We want to use our type system to make sure that we only pass around objects so
that when we call methods on those objects, they actually have those methods
to find. And that's the main thing that a type
checker for an OOP language would do. So how does this work in languages like
Java and C#? Well, each class that you define also
introduces a type. Just like when we had a data type binding
in ML and made a type. Every class in Java is also a type.
And when we declare methods, they have argument types and result types, just like
functions in ML have argument types and result types.
So, for example here in Java, I am asking to them define a Class A.
There's two methods, m1 and m2. I've omitted their bodies that's here in
the dot, dot, dot because I don't care about the bodies of these methods.
Those would be type checked. What I care about is saying that m1 takes
two arguments in e of type example and in s of type string, and it returns, we put
the return type over here on the left, something of type object.
Similarly, class A defines a method m2 that takes three arguments, one of type A,
one of type Boolean, one of type integer And returns an integer.
Now the interesting thing is how subtyping works in these languages.
So we know subclassing, right? We can have a class C that you know, is a
subclass of D. Turns out that when you do that, you also
are a subtype. In fact, no matter.
Even if you're a transitive subclass, like we studied with multiple inheritance.
You're still a subtype of the type for the superclass.
Now the way type checking works, is you can always use a subtype of what's
actually asked for. So if you have something that is a subtype
of a, you can pass that thing for the first argument m2.
Similarly, if you have a subtype of Boolean you can pass that for the second
argument subtype of integer for the third argument.
Anywhere you have something of the subtype it also has the supertype, okay so we can
pass those things along. So, that's your intro to static typing for
OOP. Now what are interfaces?
Interfaces are also types, but they're not classes.
So every class also introduces a type. Every interface introduces a type, but
just like Ruby mixins, you cannot create objects of interfaces.
Unlike a mixin, you can't put method definitions in an interface either.
Instead, the only thing you put in an interface is a, that a method exists,
these are its types of its arguments, and this is the type of its result.
So for example this interface you know, example here has two methods, m1 and m2.
M1 takes in two, ints and returns a void. M2 takes an example and a string and
returns an object, whatever types you want.
I've outlined in red here the semi-colon. There's no method body here.
You're just saying anything that has this type has these methods and the methods
take these argument type and have these result type.
So now what a class can do is implement an interface.
So in Ruby, we can have one super class. We can include any numbers of mixins.
In Java and C#, you can have one superclass, and you can implement any
number of interfaces. If you say you implement an interface,
then you better implement it. You better define, either explicitly or
through inheritance, every method that, that interface requires, and you better do
so with the correct types. In that sense, having multiple interfaces
that you implement is no problem. You just have to provide all the methods
that all of them require you to do so. And then if your class definition does
implement an interface, then the type for that class is a subtype of the interface
type. So for example here, if class a implements
example. The type checker will make sure it
actually does, and then since it does, in the rest of the program, anywhere we need
something of type example, we can instead pass something of type a.
And that gives us the flexibility to treat instances of a as things that have type
example, and another class could implement example as well.
And then if you have some code somewhere, like the body of m2 that takes an example.
It does not know whether it's being given an instance of A, or an instance of B, or
an instance of any other class that implements example, but it does know that
whatever is bound to this variable e has a method, has all the methods that the
example interface requires and they take things of the correct types.
So, interfaces provide no methods, they provide no fields so all the complications
that we had from multiple inheritance are not relevant.
They don't give you anything. If a class implements an interface all it
gives you is more obligations, things you have to do.
What they are for is to produce a more flexible type system.
That you can now define methods that take some argument of type i, where i is some
interface and then pass into that method. Anything that implements that interface.
You can also have fields, like Ruby's instance variables, who's types are
interfaces instead of classes. They're types that tell you what things of
that type have in terms of methods. So, what is going on here is Java with
interfaces has a much more flexible type system than Java without interfaces.
It lets us take two different classes in our program, have them both implement the
same interface, and then we can pass instances of either class, anywhere we
just need something with the interface type.
So they provide a lot of type system flexibility to Java, but that's really all
they provide. So in a dynamically typed language like
Ruby, you're never going to have interfaces, I would never expect them to
be added, because, you don't have a type system you are trying to make flexible.
You already have a dynamically typed language which is way more flexible.
That even Java with interfaces. So dynamic typing versus static typing is
something we studied. We know dynamic typing is more flexible,
static typing is less flexible in many ways.
We went through all of those advantages and disadvantages.
The key idea of interfaces is to start with a statically typed OOP language.
And then make the type system more powerful.
While still not being nearly as flexible as a dynamically typed language like Ruby.
Dan GrossmanProfessor
