Is that a right way of using interface callback?

Question

I read this and this and found out that in class B I need to save a reference to class A and when something happens in class B we execute a method defined by an interface that class A implements. Well somehow I understood it. I use interfaces in a bit different way to call a callback:

interface IHelper {
    void onActionDone ();
    void onActionFailed ();
}            

public class Helper implements IHelper {

    public Helper (Param param) {
        // here we do what Helper class intended to do
        // ...
        // now call the any of callbacks
        if(everything == OK) {
            onActionDone();
        } else {
            onActionFailed();
        }
    }

    @Override
    public void onActionDone() {}

    @Override
    public void onActionFailed() {}
}

public class MainClass () {
    new Helper(message) {
        public void onActionDone () {
            // here we can do anything we want after Helper will done its functions
        }
        public void onActionFailed () {
            // or not done
        }
    }
}

I find this way is more readable and easier to understand but not sure if this is a bad practice or not. So may I feel free to go this way further?

Just figured out that i don't even need an interface in this case. So it seems to me this is bad way to make callbacks( — kolyaseg, Jan 10 '16 at 21:47
_"Just figured out that i don't even need an interface in this case."_ In this case you can use NONE of the class instances but `Helper` instance to notify on done/failed actions occurred in `MainClass`. It makes these classes to be tightly coupled. Your code becomes less flexible and harder to maintain. In contrast, by using the `Observer` pattern you can use ANY class instances that implement `IHelper` interface, which makes the classes loosely coupled and the code appears to be more flexible. — Onik, Jan 11 '16 at 12:10

score 1 · Answer 1 · answered Jan 10 '16 at 22:03

In my opinion, it's not a good programming manner. Generally you even don't need interfaces to implement such design, you can override every method of a class when you're instantiating it. Actually you're not instantiating that class, you're instead instantiating an anonymous class which subclasses that class.

Let's head back to the problem, interfaces are meant to be used as literally their name suggests. They should be used as an interface between two components. From software engineering point of view, suppose you're in a team that develops a large-scale software system, in this case in design phases you an your teammates should agree on a standard and globally-acceptable interface by which two components are going to interact and additionally suppose implementation of one of this two is up to you and the other one is going to be implemented by your teammates, so for interoperability your codes must comply with that interface and so is for your teammates.

In your case, you're actually merging that standard interface into your own component, so your teammates may be unhappy with this.

TL;DR:

Your approach is not good.

score 0 · Accepted Answer · edited May 23 '17 at 12:16

So may i feel free to go this way further?

This way isn't quite correct.

What you're talking about is called Observer or Subscriber/Publisher pattern.

In simple words: a subscriber wants to receive events (magazine issues) from a publisher, so he informs (subscribe) the publisher about it. After that the publisher notifies the subscriber on an event occurred.

In your code snippet, the publisher is Helper and the subscriber is MainClass. The publisher has a form of subscription IHelper:

public class Helper {
    IHelper mSubscriber;
    ...
    void setSubscriber(IHelper subscriber) {
        this.mSubscriber = subscriber;
    }
    ...
}

The subscriber should fill in the form, i.e. implements IHelper, and notify the publisher about itself:

public class MainClass implements IHelper {
    Helper mPublisher;
    ...
    void someMethod() {
        mPublisher.setSubscriber(this);
    }
    ...
}

Now, when a new magazine issue is published by the publisher, the subscriber is being notified about that:

public class Helper {
    ...
    void newMagazineIssued() {
        mSubscriber.onActionDone();
    }

    void newMagazineFailed() {
        mSubscriber.onActionFailed();
    }
    ...
}

A listener example:

If the above said is a bit confusing to you, consider a Button you have just initialized in an Activity. The button acts as a publisher, whereas the Activity acts as a subscriber. The Activity wants to be notified when the button is clicked by a user (a new magazine issued), so it subscribes to the event with setOnClickListener() where the View.OnClickListener parameter passed to the method is the subscription form. The Activity (subscriber) fills in the form, by implementing the interface and overriding the onClick() method, and pass the form to the method (subscribe). When a click occurs, the Activity is being notified about that.

Is that a right way of using interface callback?

2 Answers2

Linked