Welcome back! Next we continue our journey with interfaces. In the last lesson we examined how to use interfaces. Now we’ll look at how to provide them in our own classes, and the kind of amazing things that this can unleash. Let’s go!
But let’s start with some debugging practice!
Write a method named retrieveValue
.
retrieveValue
takes an instance of Faulter
and returns the result of retrieving its value
property,
which has type Int
.
Seems simple!
Except there is just one small problem.
Faulter
was implemented by a friend that didn't take CS 124, and so it's getter is pretty buggy.
A lot of the time it will throw an exception rather than return the value.
But you did take CS 124, and so you know how to catch the exception and retry the call to getValue
.
Note that getValue
may fault multiple times before succeeding, and you should retry until it successfully
returns a value.
Last time we focused on using interfaces. In this lesson we’ll discuss implementing them ourselves. Along the way we’ll also discuss more about exactly how interfaces are so powerful.
As we begin to focus on using interfaces, it makes sense to think about an interface as a contract.
When you implement
an interface in one of your classes, you agree not only to provide certain methods, but also that these methods will do certain things!
Let’s return to our favorite interface—Comparable
—for an example of how to read an interface like a contract.
Keep in mind that we can use this interface in Kotlin even though it is provided by Java!
Now, let’s put what we’ve learned to use by designing a new class
and making it Comparable
!
Another important way to think about interfaces is as something called an abstraction barrier.
An abstraction barrier separates two parts of a program or system in ways that allow them to develop independently.
Again, let’s return to Comparable
to discuss exactly how that works!
Create a public class LastOdd
that implements the following interface:
This is a distinction that can be tricky for people. So let’s go through an example together and discuss the differences.
Create a public class RunningTotal
that implements the following interface:
Create a class named Location
.
Location
should define a primary constructor that accepts two fields: a latitude and longitude position,
as Double
values, in that order.
Your constructor should reject invalid latitude and longitude values by throwing an
IllegalArgumentException
.
Valid longitude values are between -180.0
and 180.0
, inclusive, while valid latitude values are between
-90.0
and 90.0
.
Both latitude and longitude properties should be externally readable, but only internally writeable.
You may need to review the private set
syntax.
Your class should also implement the IMovableLocation
interface:
Rachel Kroll may not be a household name. But she’s both an incredibly talented system administrator and a prolific author, having authored over 1000 posts on “software, technology, sysadmin war stories, and more.” Her writing is invariably both technically sharp, and infused with the wry humor of someone who has had a great many opportunities to observe the foibles of both people and machines. Not all of her writing will necessary make sense to you at first—but it will be there waiting once you have more experience and can appreciate it better, and likely largely as relevant in a decade as it is now.
Rachel Kroll has a few talks up online, but they’re long. So instead, please just read and enjoy this short piece commenting on code complexity. “Code runs on people. Please keep it simple.”
Need more practice? Head over to the practice page.