回调 类和方法的常用修饰符

来源:互联网 发布:word for mac 破解版 编辑:程序博客网 时间:2024/06/05 05:56
我们暂且不讨论回调的一些名词和运行机制,首先说为什么会存在回调这样一种调用?同步和异步机制的出现不必多说,大家心知肚明,那回调机制为什么会出现呢?在我们现实生活中,有如下这样场景:有一位老板很忙,他没有时间盯着员工干活,然后他告诉自己的雇员,干完当前这些事情后,告诉他干活的结果。这个例子其实是一个回调+异步的例子,再举一个例子,A程序员写了一段程序a,其中预留了回调函数接口,并封装好了该程序,程序员B让a调用自己的程序b中的一个方法,于是,他通过a中的接口回调自己b中的方法,到这里你可能似懂非懂了,后面会继续说明回调的出现原因。接下来我们把上面例子变成代码,看到网上很多人最后搞混了异步和回调,因此例子中不加入异步调用。(注意:回调可不是解决什么调用时间过长问题,那是异步!

首先创建一个回调接口,让老板得告知干完活如何找到他的方式:留下老板办公室地址:

[java] view plaincopy
  1. package net.easyway.test;  
  2.   
  3. /** 
  4.  * 此接口为联系的方式,不论是电话号码还是联系地址,作为 
  5.  * 老板都必须要实现此接口 
  6.  * @author Administrator 
  7.  * 
  8.  */  
  9. public interface CallBackInterface {  
  10.   
  11.     public void execute();  
  12. }  

创建回调对象,就是老板本人,因为员工干完活后要给他打电话,因此老板必须实现回调接口,不然员工去哪里找老板?

[java] view plaincopy
  1. package net.easyway.test;  
  2.   
  3. /** 
  4.  * 老板是作为上层应用身份出现的,下层应用(员工)是不知道 
  5.  * 有哪些方法,因此他想被下层应用(员工)调用必须实现此接口 
  6.  * @author Administrator 
  7.  * 
  8.  */  
  9. public class Boss implements CallBackInterface {  
  10.       
  11.     @Override  
  12.     public void execute() {  
  13.         System.out.println("收到了!!" + System.currentTimeMillis());  
  14.           
  15.     }  
  16. }  

创建控制类,也就是员工对象,他必须持有老板的地址(回调接口),即使老板换了一茬又一茬,办公室不变,总能找到对应的老板。

[java] view plaincopy
  1. package net.easyway.test;  
  2.   
  3. /** 
  4.  * 员工类,必须要记住,这是一个底层类,底层是不了解上层服务的 
  5.  * @author Administrator 
  6.  * 
  7.  */  
  8. public class Employee {  
  9.   
  10.     private CallBackInterface callBack = null;  
  11.       
  12.     //告诉老板的联系方式,也就是注册  
  13.     public void setCallBack(CallBackInterface callBack){  
  14.         this.callBack = callBack;  
  15.     }  
  16.       
  17.     //工人干活  
  18.         public void doSome(){  
  19.                     //1.开始干活了  
  20.                     for(int i=0;i<10;i++){  
  21.                         System.out.println("第【" + i + "】事情干完了!");  
  22.                     }  
  23.           
  24.                     //2.告诉老板干完了  
  25.                     callBack.execute();  
  26.         }  
  27. }  

测试类代码:

[java] view plaincopy
  1. package net.easyway.test;  
  2.   
  3. public class Client {  
  4.   
  5.     public static void main(String[] args) {  
  6.           
  7.           
  8.         Employee emp = new Employee();  
  9.           
  10.         //将回调对象(上层对象)传入,注册  
  11.         emp.setCallBack(new Boss());  
  12.           
  13.         //开启控制器对象运行  
  14.         emp.doSome();  
  15.     }  
  16.   
  17. }  

上面这个例子,大家可以和程序员A和程序员B的那个例子结合对照下。

看了上面的例子,有的人可能认为,这不是面向接口的编程吗?怎么会是回调,你再好好想想,咱们面向接口的编程的调用关系?在三层中,当业务层调用数据层时,是不需要把业务层自身传递到数据层的,并且这是一种上层调用下层的关系,比如我们在用框架的时候,一般直接调用框架提供的API就可以了,但回调不同,当框架不能满足需求,我们想让框架来调用自己的类方法,怎么做呢?总不至于去修改框架吧。许多优秀的框架提几乎都供了相关的接口,我们只需要实现相关接口,即可完成了注册,然后在合适的时候让框架来调用我们自己的类,还记不记得我们在使用Struts时,当我们编写Action时,就需要继承Action类,然后实现execute()方法,在execute()方法中写咱们自己的业务逻辑代码,完成对用户请求的处理。由此可以猜测,框架和容器中会提供大量的回调接口,以满足个性化的定制。

不知道上面这个例子懂了没有?我们现在可以想象Filter和Interceptor的区别了,这两者其中最大的一个区别是Filter是基于回调函数,需要容器的支持,没有容器是无法回调doFilter()方法,而Interceptor是基于Java的反射机制的,和容器无关。那到此是否又将反射和回调搞混了呢?请见我讲Java动态代理的博客《以此之长,补彼之短----AOP(代理模式)》。

总之,要明确的一点是,首先要搞清回调函数出现的原因,也就是适用场景,才能搞清楚回调机制,不然事倍功半。

最后,再举一例,为了使我们写的函数接近完美,就把一部分功能外包给别人,让别人个性化定制,至于别人怎么实现不管,我唯一要做的就是定义好相关接口,这一设计允许了底层代码调用高层定义的子程序,增强程序灵活性,和反射有着异曲同工之妙,我觉得这才是回调的真正原因,以上是我个人一些理解,望讨论!









我们为什么要用回调函数呢?
记得在一次C++开发面试的时候被被一位主面官问到过这个问题,现在再回答一遍。

我们对回调函数的使用无非是对函数指针的应用,函数指针的概念本身很简单,但是把函数指针应用于回调函数就体现了一种解决问题的策略,一种设计系统的思想。
在解释这种思想前我想先说明一下,回调函数固然能解决一部分系统架构问题但是绝不能再系统内到处都是,如果你发现你的系统内到处都是回调函数,那么你一定要重构你的系统。回调函数本身是一种破坏系统结构的设计思路,回调函数会绝对的变化系统的运行轨迹,执行顺序,调用顺序。回调函数的出现会让读到你的代码的人非常的懵头转向。

那么什么是回调函数呢,那是不得以而为之的设计策略,想象一种系统实现:在一个下载系统中有一个文件下载模块和一个下载文件当前进度显示模块,系统要求实时的显示文件的下载进度,想想很简单在面向对象的世界里无非是实现两个类而已。但是问题恰恰出在这里,显示模块如何驱动下载进度条?显示模块不知道也不应该知道下载模块所知道的文件下载进度(面向对象设计的封装性,模块间要解耦,模块内要内聚),文件下载进度是只有下载模块才知道的事情,解决方案很简单给下载模块传递一个函数指针作为回调函数驱动显示模块的显示进度。

在面向对象的世界中这样的例子还真不少,造成这样的问题的根源,相信大家已经从上面的叙述中体会到了,就是面向对象的程序设计思想,就是设计模式中要求的模块独立性,高内聚低耦合等特性。

封装变化的编程策略给编程人员第一位的指导思想就是面向接口编程米,即设计模式中提到的面向虚拟编程而不是面向实现。这样的编程思想极大地革新了编程世界,可以说没有这一原则就没有面向对象的程序设计,这一原则给程序设计一种指导思想即如何更高的将现实模型映射成程序模型。这样的设计思想在极大地催生高度独立性模块的同时削弱了模块间的协作性,也就是耦合性,它使得模块间更多的从事着单向的调用工作,一个模块需要某种服务就去找另一个模块,这使得程序呈现出层次性,高层通过接口调用底层,底层提供服务。但是现实世界中严格遵循现层次特性的系统是很少见的,绝对的MVC是不存在的,因为更多的模块要求通并协作,可见没有耦合就没有协作没有好的调用关系,耦合真的不是错。

既然我们需要模块间的协作,同时我们又厌恶的摒弃模块间你中有我我中有你的暧昧关系那如何生成系统呢,答案是函数指针(不一定一定是函数指针)也就是使用回调的方式。如果一个对象关心另一个对象的状态变化那么给状态的变化注册回调函数让它通知你这类状态的改变,这样在封装了模块变化的同时实现了模块间的协作关系另辟独径的给对象解耦。


常见的修饰符的用法:

类:

一般情况下,任意的类都用public修饰。

如果是抽象类:public abstract class Demo {}

如果是最终类:public final class Demo {}

成员变量:

一般情况下,成员变量都用private修饰。

如果是常量:

public static final

 

构造方法:

一般情况下,构造方法用public修饰。

如果不想外界创建对象,用private修饰。

 

成员方法:

一般情况下,成员方法用public修饰。

如果是抽象方法:public abstract void show();

如果是静态方法:public static void show(){}

如果是最终方法:public final void show(){}

  

1 0
原创粉丝点击