java中步骤的参数可以是方法

咪……读过设计模式相关资料的话会知道这是个策略模式的应用，帅是帅，不过90年代中期被GoF总结出来之后大家也就是这么用着，呃呵呵。

关于Java中是否应该引入闭包的争论，hmm，某种程度上说策略模式是闭包的退化形态，所以有人想要更简洁的语法得到更强的能力，就想到该往Java里加入闭包了。难说这对Java来说会不会重复泛型的糟糕……

你太牛了，能不能说说，你是哪个学校的啊，莫非传说中的水木清华？？？？？

我也感觉java中应该有闭包的。对闭包也只是停留在概念阶段，呵呵

多用几年Java，读读书，在实际代码中吃点亏之类的，应该能知道这些知识的。这跟牛不牛没关系……JE上的牛人多的是了呢，呵呵。另外我是南京大学的，呃呵呵 =v=


Java中加入闭包可能迟了点，只能这么说。已经有太大的历史包袱压在语言上，而且社区内对新的语言结构总是持抗拒态度的人多，所以……不好说。
Java的闭包方案中，BGGA方案是最强大但也最复杂的。这个方案想“要做就一口气做彻底”，或许彻底过头了。在函数式语言中，因为不强调控制流的概念（而是使用递归和高阶函数来实现控制流），所以没有“非本地返回”（non-local return）的问题；在许多支持闭包的命令式语言中，嵌套函数中return的语义也是跟普通函数一样，只做“本地返回”。（local return）

本地返回和非本地返回是什么意思呢？用例子来说明：
假设Java支持闭包，那么我们很可能可以写出：

public class Foo {
    private static void bar() {
        Integer[] array = new Integer[] { 2, 4, 3, 1, 0 };
        Arrays.sort<Integer>(array, (Integer x, Integer y) => { return x - y; });
        System.out.println("done!");
    }
    
    public static void main(String[] args) {
        bar();
    }
}

注意到Arrays.sort那行的调用，第二个参数使用了闭包来实现原本Comparator<E>接口里的compare()方法。嗯这个例子可能不太好，因为Comparator<E>接口里有两个方法（另一个是equals()）；诶，顺便假设Comparator<E>里没有equals()方法，而是“单方法接口”吧。另外Arrays.sort()是有int[]版本的重载的，也暂时无视掉它吧……一时想不到啥好例子。
注意到上面例子里的return如果表示的是本地返回，则Arrays.sort()是调用方、闭包是被调用方，因而闭包的返回目标是Arrays.sort()。当然，执行完整个排序之后，控制流回到bar()里，然后继续执行println()，我们会看到done!。

但如果那个return是“非本地返回”呢？那么闭包里的return语句的返回目标就是bar()的调用者，在这里例子里也就是main()；Arrays.sort()在调用那个闭包的时候就会遇到return语句，导致控制流跳出bar()直接回到main()。这样我们就不会看到done!的输出，排序也不会正确进行。事实上，如果return表示的是非本地返回，这段代码很可能无法编译：return语句的返回类型是Integer/int，而bar()的签名里写着返回类型是void，类型不匹配因而有问题。不过这个例子里请暂时忽略掉编译的成功与否的问题……反正这个闭包语法也是造出来的，呵呵。

OK，现在主流语言里支持闭包且支持非本地控制流的语言，其中一个例子就是Ruby。也是随便写个例子：

def foo
  [1, 2, 3].each { |i| return i if 0 == i % 2 }
  nil
end

这段代码里的return就是一个非本地返回，在遇到i是偶数的时候将i返回，否则在遍历完成后返回nil。（好孩子请直接用Enumerable#find ...）
而下面这段代码片段里的return则是传统的本地返回：

def foo(f)
  puts f.call
end

def bar
  foo(lambda { return 'bar' })
  puts 'done!'
end

所以执行完这段之后，我们可以看到输出bar和done!。（好孩子请不要在这里写return……省略return效果一样）

用个实用点的例子：

def foo
  i = 0
  loop do
    break if 3 == i
  end
end

这里，loop是Ruby标准库里的一个函数，而do...end中间的是一个block，也就是Ruby里的闭包。这里的break应该使控制流直接跳出loop回到foo，而不应该break回到loop里面。如果没有非本地控制流的语义，这个break就不好写了。

换句话说，在Ruby里，同样是Proc对象，return、break、next等控制流语句的语义是取决于该Proc对象是lambda还是普通的Proc；是lambda的话就是用本地控制流语义，反之则使用非本地控制流语义。

反对BGGA的Java程序员本恐惧这种怪怪的差异会撑爆它们的头脑，所以抗拒着。
而其它支持闭包的主流C-like语言里，C#、JavaScript、ActionScript 3等都只支持本地控制流语义，也是对这复杂性有所考虑的结果。嘛。

java中的死脑子真的很多....
不过他们对新技术的培训预计一点也不过分

java老虎在笼子中是现在jdk的最好形容.
空有好的想法/牛X的语法 但没办法快速推广.

不过java的衍生语言  groovy支持闭包哈~~~

有个同志写了

一个java版的C的语义解释器.....
说是是大学毕设时把题目看反了..

<div class="quote_title">抛出异常的爱 写道</div>
<div class="quote_div">
<div class="quote_title">kimmking 写道</div>
<div class="quote_div">
<div class="quote_title">抛出异常的爱 写道</div>
<div class="quote_div">java中的死脑子真的很多....<br />不过他们对新技术的培训预计一点也不过分<br /><br />java老虎在笼子中是现在jdk的最好形容.<br />空有好的想法/牛X的语法 但没办法快速推广.</div>
<br />不过java的衍生语言  groovy支持闭包哈~~~</div>
<br />有个同志写了<br /><br />一个java版的C的语义解释器.....<br />说是是大学毕设时把题目看反了..<br /><br /></div>
<p> </p>
<p>强悍!!!</p>

嗯，不过Groovy的闭包与C#、JavaScript一样只有本地跳转语义，而不像Ruby那样同时拥有本地和非本地跳转语义。所以Groovy程序员不会被怪怪的非本地跳转把脑子撑爆 XDD

那个...传方法的话 直接反射后传Method不就行了吗...

由VM直接支持的动态方法分发（dynamic method dispatch）再怎么慢，或者说反射再怎么快，也肯定是前者比后者快；且不提Java中反射调用方法的开销比正常的方法调用大不少。所以在Java里要“传递方法”的话，策略模式还是比反射来得顺畅

那个可以跳出n层，多好…… 平时尽量少用 return 避免烦恼……

是撒，写Ruby代码的时候我好久没需要写过return了。看到那些每个方法里都有return的Ruby代码风格还不习惯 T T
不过要跳出n层还是得靠throw/catch吧？……

一般的throw/catch是一个方法。

return 可以无视 block 直接进行方法返回。try this：

def a
  yield
  puts 'a'
end

def b
  a{return 'x'}
  puts 'b'
end

b

所以一般正常的 block 返回值应该用 yield 或者干脆不写……

> <，没看上一页就相当然的 re 了……

出现这么多语法，都是因为我们打死了 goto ……

“一般”的goto只能在局部作用域里跳转，你看C里要跨函数跳转还得longjmp。但Ruby的throw/catch就能做远程跳转，比“一般”的goto更goto了 XDD

楼上是在比谁的设计更像外星人么

感觉你穿西装好看，这个头像不好看哦

<div class="quote_title">抛出异常的爱 写道</div>
<div class="quote_div">楼上是在比谁的设计更像外星人么</div>
<p> </p>
<p>确实很火星</p>

此人已死 有事烧纸 的那种