Video: Using interfacesRelated to the idea of Inheritance is a concept supported by many object-oriented languages which usually referred to as an interface. Now this can get a little puzzling because the word Interface is heavily used in computing and has several different meanings. But the term here does not mean user interface. What we are talking about here in this discussion is something that's actually created very similar to a class but with no actual functionality, no actual code, no behavior. It's really just a list of method signatures.
Viewers: in countries Watching now:
Most modern programming languages, such as Java, C#, Ruby, and Python, are object-oriented languages, which help group individual bits of code into a complex and coherent application. However, object-orientation itself is not a language; it's simply a set of ideas and concepts.
Let Simon Allardice introduce you to the terms—words like abstraction, inheritance, polymorphism, subclass—and guide you through defining your requirements and identifying use cases for your program. The course also covers creating conceptual models of your program with design patterns, class and sequence diagrams, and unified modeling language (UML) tools, and then shows how to convert the diagrams into code.
- Why use object-oriented design (OOD)?
- Pinpointing use cases, actors, and scenarios
- Identifying class responsibilities and relationships
- Creating class diagrams
- Using abstract classes
- Working with inheritance
- Creating advanced UML diagrams
- Understanding object-oriented design principles
Related to the idea of Inheritance is a concept supported by many object-oriented languages which usually referred to as an interface. Now this can get a little puzzling because the word Interface is heavily used in computing and has several different meanings. But the term here does not mean user interface. What we are talking about here in this discussion is something that's actually created very similar to a class but with no actual functionality, no actual code, no behavior. It's really just a list of method signatures.
In Java an interface would be written something like this, just the word interface instead of class. Give it a name. I am calling it Printable, and then two method signatures with absolutely no functionality, you're not allowed to put functionality inside an interface. Now you might think, well, what's the point of this? Well, the idea is that if we create a new class and then choose to use an interface--and the term we use is implementing an interface--it's like signing a contract.
What we do is create this class, use the word implements to say we are supporting that, we are promising to do something, we are promising to create methods with particular names. We have the freedom to do it anyway we want to, but we are promising to do it, it's a contract that we are signing. And the point of contracts, of course, is that you're never the only one to sign. With interfaces, the more classes implement the same interface the better. So if I've used the word implements here, I've signed the contract. Then that means I have to provide those two methods in my class and some kind of implementation for them, or I'll get a compile error.
But you still might be thinking, okay, what's the point, I have methods with a particular name. Well, we are still missing one piece. The benefit is that going forward we could have many different classes choose to implement the same interface, and now other parts of the app can use objects with interfaces without knowing anything else about how those objects work. For example, if some other place in my code, I have a big list of objects that I'm iterating through, I could just ask, does this particular object support that printable interface? In Java I'd use instance of other languages do it different ways, but the concept is the same, we can just ask, does the object that I have support that particular interface, if it does, I know I can use it.
I know I can call the print method on any object that implemented the printable interface. I might not know anything else about how that object works, but I know it can print, and I know the exact signature of the method to call. In UML we represent interfaces in the same class style boxes before, but we are using an interface tag with the angle quotes here, that you make to surround it. And then just the list of public signatures. And if we say we're implementing this interface, then from my class I will use a dotted line and the same arrow that we used for Inheritance, but the dotted line represents interface implementation rather than Inheritance.
Now although it would seem that regular Inheritance will be more powerful, it is true that many developer's favorite using interface is to provide formal list of methods to support rather than using Inheritance and dealing with lots of pre-provided functionality that may or may not be correct. In fact, there is a well-known phrase from the classic design patterns book that recommends the developers program to an interface not to an implementation, simply because it's then the developer's choice how to implement those methods rather than being provided with that code.
Not all languages support this idea and sometimes it uses different names, but interface is the most commonly known term. In Objective-C interface has a different meaning, but we can support the same idea with what's called a Protocol. And a Protocol, again, is just a list of method signatures. So instead of seeing we implement an interface, in Objective-C we can conform to a Protocol. Now I am not going to get much more into interfaces into this course because I want to stay language-independent, but I do recommend that you become familiar with the implementation of this idea in your chosen language because they are often more future-friendly method than using Inheritance.
There are currently no FAQs about Foundations of Programming: Object-Oriented Design.