Interface function: Utility to span hierarchies?

Question

As I stated in another post (Fragment to Activity Communications) I don't understand interfaces. I am trying to understand OOP and am reading through this site's posts and books such as "Thinking in Java" by Bruce Eckel (TiJ). Perhaps a big part of my problem is that I haven't been trained in OOP. I'm an electrical engineer who has written assembly language operating systems for 8 bit controller embedded systems. Procedural languages are relatively easy to understand, OOP still has some mysteries, Interfaces are one of them. I have two questions in this post.

1. Interface as template:

In TiJ, as in most explanations of interface, Bruce writes:

"An interface says, "All classes that implement this particular interface will look like this." Thus, any code that uses a particular interface knows what methods might be called for that interface, and that’s all. So the interface is used to establish a "protocol" between classes. (Some object-oriented programming languages have a keyword called protocol to do the same thing.)"

From What is an interface in Java?, I see the following, which seems to be saying the same thing as immediately above:

"What it's useful for: One of its uses is for it to be used as a face for a service. When two parties work together to form a service-requester & service-provider kind of relationship, the service provider provides the face of the service (as to what the service looks like) in the form of an interface."

To me, it would be analogous to providing a person who wants to build a computer (analogous to the program) a set of computer parts, even parts that they wouldn't use (the hardware analogy to an SDK). In that HW set, one would find a bunch of FPGAs (analogous to interfaces) that need to be programmed as the CPU. FPGAs are flexible, they can be almost any CPU, in SW, and be reprogrammed in-circuit. So, Interfaces seem to provide a "template" that the programmer can code as required for their specific circumstance.

Is this close?

2. Interface to span hierarchies

In Android, it seems intended that one use interfaces to provide communication between Fragments via their Activities (https://developer.android.com/training/basics/fragments/communicating.html). To me, that seems to have something to do with (TiJ):

"Whenever a method works with a class instead of an interface, you are limited to using that class or its subclasses. If you would like to apply the method to a class that isn’t in that hierarchy, you’re out of luck. An interface relaxes this constraint considerably. As a result, it allows you to write more reusable code."

From Proper interface use and explanation I see the following, which seems to be saying the same thing as immediately above:

"A nice example for use of inheritance and interfaces will be: Lets say you are building a software for electronics devices. And the scenario is like (parent class -> inherited class) : Gadgets -> Electronic Gadgets -> Telephony Gadgets -> Mobiles -> Smart Phones -> Tablest. And say Mobiles, Smart Phones and tablets have a common feature of FM-RADIO. This feature is available in other Gadgets which are not Telephony Gadgets. Now it will be perfect to use FM-Radio as an interface. Every gadget will provide their own definition of FM-Radio but all will share same functionality."

So, in regards to communicating between Fragments, the hierarchy of Activity is:

java.lang.Object
   ↳    android.content.Context
       ↳    android.content.ContextWrapper
           ↳    android.view.ContextThemeWrapper
               ↳    android.app.Activity

While the hierarchy of Fragment is:

java.lang.Object
   ↳    android.app.Fragment

Inside the compiler, do interfaces provide the utilty to connect between those different hierarchies to provide communication between Fragments?

Answer 1

1. Is this close?

Since I'm not an electrical engineer, I don't know! But I can try to put the Java concept of an interface into plain english.

An interface defines a list of "stuff" an implementing class can "do", but doesn't at all define how those classes will "do" that "stuff". One classic Java example is the List interface, as well as the ArrayList and LinkedList implementing classes. Since both implement the List interface, you can add() items to them, or get() items from them, or even clear() all items out of them. But ArrayList does all of these things in a very different way from LinkedList.

The other key point is that when you're using interfaces correctly, you don't care which implementing class you're working with. When you're writing code that uses a List, you should be able to freely swap ArrayList out for LinkedList without changing any of your code. Of course, you might have reasons to prefer one implementation over the other, but your program should be functional either way.

2. Inside the compiler, do interfaces provide the utilty to connect between those different hierarchies to provide communication between Fragments?

It's a little hard for me to understand exactly what you're asking, but I suspect that this question is evidence that you've misunderstood the precise reason why using interfaces is recommended for communication between a Fragment and an Activity.

Imagine you have a Fragment (which, remember, is supposed to be a reusable component) that allows you to choose a color. Your Activity needs to use this color to draw a paintbrush stroke or something like that. One way to return this color information from the Fragment to the Activity would be to write something like this:

// in the Fragment
private void sendColor(int color) {
    PaintingActivity activity = (PaintingActivity) getActivity();
    activity.setPaintbrushColor(color);
}

// in the Activity
public void setPaintbrushColor(int color) {
    myPaintbrushColor = color;
}

But what happens if you have some other Activity that also wants to be able to use this Fragment to choose a color? Your Fragment would crash with a ClassCastException because it is dependent on the specific type of your Activity.

The solution is to define an interface for anyone who wants to be able to get a color from the Fragment, and then to have your various Activity classes implement that interface.

// interface definition
public interface OnColorSelectedListener {
    public void onColorSelected(int color);
}

// in your Fragment
private void sendColor(int color) {
    OnColorSelectedListener listener = (OnColorSelectedListener) getActivity();
    listener.onColorSelected(color);
}

// your Activity
public class PaintingActivity implements OnColorSelectedListener {

    ...

    @Override
    public void onColorSelected(int color) {
        myPaintbrushColor = color;
    }
}

Now that your Fragment is dependent on an interface instead of a particular Activity type, it can be reused with any Activity that implements OnColorSelectedListener.

So, in short, interfaces provide the ability to connect one component to a "generic" other component without worrying about the specific type of that other component.

Answer 2

General rule is relationship type. IS A is base class. CAN DO is interface. Even an abstract class can have implementation for those that inherit from it.