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 exec
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.
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.