Hi! In this video we're going to think about interfaces — effectively fully abstract classes.

As per usual, we're going to look at some code that's been ready written.

So, in the previous demo, we looked at how we could create abstract classes, and you'll remember that when a class is abstract, it will contain one or many abstract methods, and an abstract method contains no code.

It becomes purely a signature.

We could take that concept to an extreme and declare all the methods and properties within an abstract class as being abstract and have no code behind any of them.

And when you go to that extreme, a better notation to use is that of interfaces, which is where we're going to go in this demo.

So, my starting point is an interface, so I declare something using the interface keyword rather than class.

I specify a type name for this and I prefix that type name with a capital I.

This is convention; we don't have to do that, but it's good practice to do it.

I for interface.

And, within there, you can see we've got two methods: withdraw money, deposit money, both just signatures and, interestingly, no use of a modifier, no keyword public here, don't need to do that at all when you're defining interfaces.

So, this is effectively a fully abstract class.

Let's see how we implement that.

So, if I go to our current account class, you can see that it appears to be inheriting from IBankAccount, and, effectively, it is doing that, but there's no code to inherit because all of the codes are just signatures.

So, instead, we use the term implement rather than inherit.

But the definition is moot, it's no great shakes one way or the other.

Inside this CurrentAccount class, we define a deposit money method and a withdraw money method.

And because this is a CurrentAccount class, we worry about the overdraft limit and it's kind of the same kind of code as we saw before.

If I look at the SavingsAccount class, it too implements IBankAccount and it, too, therefore, has to be given a deposit money method and a withdraw money method.

And the withdraw money method now cannot have an overdraft limit associated with it because savings accounts cannot go overdrawn.

So, slightly different logic behind the withdraw money method.

Other than that, it's kind of the same code as before.

We've given ourselves an add interest method, which is something peculiar to savings accounts, and not being given to us or forcing us by the underlying interface.

Remember we also looked at ISA accounts, previously, and ISAAccount inherits from SavingsAccount.

Can I do that if SavingsAccount implements interface?

Well, of course I can because, I know the SavingsAccount object has an absolute guaranteed pair of methods: deposit money and withdraw money.

So, from the ISAAccounts perspective, there's nothing different to what went on before.

Deposit money needs to be overridden because there's a limit to how much money you can put into an ISA account, so you need to manage a test for the maximum value being put into it.

If I then go and look at the underlying logic that uses those classes, I start off by declaring, well, instantiating a current account object.

But notice I declare that as an IBankAccount object. Can I do that? Of course I can.

It's the same kind of reasoning behind interfaces as we had behind abstract classes.

You can't create instances of IBankAccount objects, but you can declare variables of that type and make them point at specialized objects that implements that interface, and so there'll be no problem with this new current account being able to withdraw money from it and to check on its balance.

I then go on to create concrete versions of CurrentAccount objects, SavingsAccount objects, and ISAAccount objects being looked at as their specific types.

But then I create a list of IBankAccount and I add all four different bank account objects into that collection.

Can I do that? Well, yes, I can because they all either directly or at some point implement IBankAccount objects.

So, that's a perfectly OK thing to do.

And, therefore, what I can do for each of the objects inside those collections is check their balances, deposit money, withdraw money, and check their balances again, and would expect them to behave all in exactly the same way.

And so, I can run the program to see that effect.

And we notice that their balances all start off at zero. They all successfully have £100 added, £100 withdrawn, and their balances will go back to 0.

So, all their deposit methods and withdraw methods will run successfully in spite of them being specialized objects and in spite of the IBankAccount interface supporting no concrete code.

So, in this video, we've seen how to implement interfaces and seen how they are very similar to fully abstract classes.

Practical example of declaring and using interfaces

About