Interfaces

Loading...

From the course by University of Washington

Programming Languages, Part C

216 ratings

University of Washington

Programming Languages, Part C

216 ratings

[As described below, this is Part C of a 3-part course. Participants should complete Parts A and B first -- Part C "dives right in" and refers often to material from Part A and Part B.] This course is an introduction to the basic concepts of programming languages, with a strong emphasis on functional programming. The course uses the languages ML, Racket, and Ruby as vehicles for teaching the concepts, but the real intent is to teach enough about how any language “fits together” to make you more effective programming in any language -- and in learning new ones. This course is neither particularly theoretical nor just about programming specifics -- it will give you a framework for understanding how to use language constructs effectively and how to design correct and elegant programs. By using different languages, you will learn to think more deeply than in terms of the particular syntax of one language. The emphasis on functional programming is essential for learning how to write robust, reusable, composable, and elegant programs. Indeed, many of the most important ideas in modern languages have their roots in functional programming. Get ready to learn a fresh and beautiful way to look at software and how to have fun building it. The course assumes some prior experience with programming, as described in more detail in the first module of Part A. Part B assumes successful completion of Part A. The course is divided into three Coursera courses: Part A, Part B, and Part C. As explained in more detail in the first module of Part A, the overall course is a substantial amount of challenging material, so the three-part format provides two intermediate milestones and opportunities for a pause before continuing. The three parts are designed to be completed in order and set up to motivate you to continue through to the end of Part C. Week 1 of Part A has a more detailed list of topics for all three parts of the course, but it is expected that most course participants will not (yet!) know what all these topics mean.

From the lesson

Section 9 and Homework 7 (Second Module With Ruby)

Welcome to the second week of Part C where we will focus on how functional programming and object-oriented programming encourage such "exactly opposite" decompositions of problems that they are "more alike than you might realize". This is a key opportunity to synthesize much of what we have learned so far. As the welcome message discusses in more detail, we will go a bit beyond this to touch on some related advanced topics and then dive into the last -- and challenging -- programming assignment, which involves porting an interpreter from ML to Ruby.

OOP Versus Functional Decomposition12:51

Adding Operations or Variants11:08

Binary Methods with Functional Decomposition7:18

Double Dispatch14:46

Optional: Multimethods6:36

Multiple Inheritance10:18

Optional: Abstract Methods8:51

Meet the Instructors

Dan Grossman
Professor
Computer Science & Engineering

[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.

Explore our Catalog

Join for free and get personalized recommendations, updates and offers.

Coursera provides universal access to the world’s best education, partnering with top universities and organizations to offer courses online.

© 2018 Coursera Inc. All rights reserved.

Download on the App Store

Get it on Google Play