5 回答

TA贡献1848条经验 获得超2个赞
这本质上是一个方法调用。假设我们有两个类A和B,我们期望在A的某个时刻调用B的某个方法,我们可以让A保持一个B的引用,在合适的时机进行方法调用:
class B {
void doSomething() {}
}
class A {
private B b;
public void setB(B b) {
// 保持一个B的引用
this.b = b;
}
public void testMethod() {
// ...
// 在A的某个时刻调用B的某个方法
b.doSomething();
// ...
}
}
以上代码实现了,在A的某个时刻(发生某件事情的时候),我们通知B去做一些事情,这就是一个简单的监听模式。你看,这里并不是B时时刻刻去监听A的动作,而是在某个时刻A主动触发了B的方法。
在这里,把B换成Listener,就变成了我们熟悉的监听器。
所以我们可以写一个B的子类,也就实现了一个自定义监听器:
class SubB extends B {
@override
void doSomething() {}
}
void main() {
A a = new A();
// 给A设置我们自定义的监听器
a.setB(new SubB());
a.testMethod();
}
在设计模式方面,有一条推荐的做法,叫做“多用组合,少用继承”,意思是说应该多用接口而少用继承,我们把上面的B改成接口:
interface B {
void doSomething();
}
然后把之前继承的实现换成接口的实现:
class SubB implements B {
void doSomething() {}
}
void main() {
A a = new A();
// 给A设置我们自定义的监听器
a.setB(new SubB());
a.testMethod();
}
你可以看到,用法和之前是完全一样的。
把interface B换成interface OnClickListener,是不是就清晰很多了?这在设计模式中叫做观察者模式。

TA贡献1803条经验 获得超6个赞
不要字面的理解监听器,它不是主动去检查时间是否发生的,所以不存在每时每刻这种说法。
对于我们来说,Android中的Listener其实只是一种Callback,是回调方法。是当事件发生时,由事件发起者或者内部处理者调用的方法。
自己编写的Listener类并不是因为继承了谁谁谁就能监听事件,而是要想办法告诉事件的发起者或者内部处理者,事件发生时,需要调用这个Listener中的指定方法,这也就是通常所要做的setListener的过程。
你给出的代码里已经把这个逻辑演绎得非常清楚,请先仔细看看代码。

TA贡献1780条经验 获得超1个赞

TA贡献1836条经验 获得超13个赞
其实你只要上课认真听讲了,下课认真把老师打的代码打了一遍,你就明白这个问题了,
可以肯定的是,总是喜欢把问题拖着,到后来再弄清楚,这样是不行的。
建议多打代码,每天不少于700行。
你觉得没代码打?问别人弄清楚的问题,那个代码一定要打3遍,没代码打就打些有意义的小程序。
坚持打代码,就是从一开始就坚持强大。
添加回答
举报