CODEWITHSUNDEEP
javainterfacepolymorphism
Alexander Mills
Alexander Mills

Reputation: 100020

Where do the parameters come from when interfaces are automatically-implemented?

Using Eclipse, I decided to implement an interface. Eclipse generates the method signatures automatically.

Some of the methods from the interface have parameters passed into the method. Where do these parameters come from? They are not in the interface I am implementing, right?

For example, when implementing the ActionListener interface, we are forced to implement this method:

@Override
public void actionPerformed(ActionEvent arg0){
...
}

Where is the ActionEvent object coming from?

Upvotes: 2

Views: 165

Answers (3)

Platinum Azure
Platinum Azure

Reputation: 46193

An interface definition in Java can be thought of more like a contract or promise than anything else. By claiming to implement an interface, a class is promising that it will have an implementation for the methods defined within. For example, a class implementing ActionListener promises to provide an implementation for a method actionPerformed, which returns nothing and which requires an ActionEvent object to be passed into the method.

Only when the method is called by some other class does the ActionEvent object need to exist and pass in. In the interface definition and in the class's implementation, it merely assumes that an ActionEvent will be passed in. That's all. It's the exact same as any other method taking in a parameter-- the caller must provide the data in question, and the method simply makes use of it.

As for why actionPerformed requires an ActionEvent, that can be answered on two different levels:

  1. Because the interface definition for ActionListener mandates it by requiring that exact method signature. (This is the "why won't it compile if I don't" answer.)
  2. Because the Java API designers, who created the interface, decided that that's how the interface should work. (It makes sense, because ActionListener is supposed to listen for "action events", so it's only natural that an object with the action event's information should be passed in. It is the responsibility of the implementing class to act on the information provided. This is the "why did they make it this particular way" answer.)

What's the point of all of this? The answer is polymorphism: In the case of ActionListener, it is possible to register a whole group of ActionListeners with different implementations with a Swing component, and all of them can be invoked the same way since they all are guaranteed to have a method void actionPerformed(ActionEvent e). This means that the Swing component can only worry about the interface (what the behavior is expected to be) of each listener, rather than the implementation (how that behavior actually works and/or how to invoke it).

Upvotes: 3

Caffeinated
Caffeinated

Reputation: 12484

ActionEvent here is what needs to be supplied to actionPerformed, it says so here in the API

Much of programming is using pre-existing tools. i.e if I want to make a tic-tac-toe game, where you click around - i have to use ActionEvent or java.MATH

Upvotes: 2

NPE
NPE

Reputation: 500367

Now, where do these parameters come from? They certainly are not in the Interface that I am implementing, right?

Actually, wrong. They are part of the interface that you're implementing.

Let's take ActionListener as an example. From the documentation:

void actionPerformed(ActionEvent e)
                     ^^^^^^^^^^^^^

Upvotes: 4

Related Questions