blocks|key|193856|text|只有一个(或几个)方法的接口是高度有用的Strategy+pattern的关键，它是“一些提倡使用这些类型的接口的设计标准”。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|193857|另一个常见的场景是当您想要回调时。Foo将Bar作为异步任务调用，当Bar完成某项任务时，使用回调将结果发送回Foo+--回调可以是一个只包含一个方法的接口。(一个例子是Android中的许多监听器，Swing中的事件监听器...)|193858|另外，如果你有两个紧密耦合的类(让我们称它们为Foo和Bar)。Foo几乎使用了Bar的所有方法，但Bar只需要来自Foo的一些方法。Foo可以实现FooInterface，然后将其发送到Bar。现在耦合更松散了，因为Bar只知道FooInterface，而不关心实现类包含的其他方法。|style|CODE|193859|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Strategy_pattern^0|K|G|0|0|0|22|C|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@$A|S|B|T|1|U]]|C|$]]|$1|D|3|E|5|6|7|V|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|W|8|@$A|X|B|Y|H|I]]|9|@]|C|$]]|$1|J|3|-4|5|6|7|Z|8|@]|9|@]|C|$]]]|K|$L|$5|M|N|O|C|$P|Q]]]]

Interfaces with only one (or few) methods is the key to the highly useful <a href="http://en.wikipedia.org/wiki/Strategy_pattern" rel="noreferrer">Strategy pattern</a>, which is "some design standard which advocates the use of these type of interfaces".

Another common scenario is when you want a callback. Foo calls Bar as an asynchronous task, and when Bar is finished with something, the result is sent back to Foo using a callback -- which can be an interface containing only one method. (An example of this is the many listeners in Android, Event Listeners in Swing...)

Also, if you have two classes that are tightly coupled with one another (let's call them Foo and Bar). Foo uses nearly all of Bar's methods, but Bar only needs some a few of those from Foo. Foo can implement <code>FooInterface</code> which is then sent to Bar. Now the coupling is looser, because Bar only knows about the FooInterface, but does not care about the other methods the implementing class contains.

blocks|key|193899|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|193900|在什么情况下，保留单一方法接口是有意义的？|blockquote|193901|193902|193903|在这种情况下，当您需要一个只有一个方法的接口时。|193904|接口用于封装几个类的公共行为。因此，如果在代码中有几个地方只需要调用有限的类方法集，那么是时候引入一个接口了。方法的数量取决于您需要调用的确切内容。有时你需要one方法，有时你需要two或more，有时你需要don't+need+methods+at+all。重要的是，您可以将行为与实现分开。|offset|length|193905|entityMap|0|LINK|mutability|MUTABLE|url|http://docs.oracle.com/javase/7/docs/api/java/lang/Comparable.html|1|http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Delayed.html|2|http://docs.oracle.com/javase/6/docs/api/java/util/Deque.html|3|http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html^0|0|0|0|0|0|27|3|0|2I|3|1|2M|4|2|2W|P|3|0^^$0|@$1|2|3|-4|4|5|6|Z|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|10|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|11|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|12|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|13|7|@]|8|@]|9|$]]|$1|H|3|I|4|5|6|14|7|@]|8|@$J|15|K|16|1|17]|$J|18|K|19|1|1A]|$J|1B|K|1C|1|1D]|$J|1E|K|1F|1|1G]]|9|$]]|$1|L|3|-4|4|5|6|1H|7|@]|8|@]|9|$]]]|M|$N|$4|O|P|Q|9|$R|S]]|T|$4|O|P|Q|9|$R|U]]|V|$4|O|P|Q|9|$R|W]]|X|$4|O|P|Q|9|$R|Y]]]]

<blockquote>
 In what scenarios does it make sense to keep single method interfaces?
</blockquote>

In such a scenarios when you need an interface with only one method.

Interfaces are used to encapsulate a common behavior of several classes. So if you have several places in your code where you need to call only limited set of class methods, it's time to introduce an interface. The number of methods depends on what exactly do you need to call. Sometimes you need <a href="http://docs.oracle.com/javase/7/docs/api/java/lang/Comparable.html" rel="nofollow">one</a> method, sometimes <a href="http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Delayed.html" rel="nofollow">two</a> or <a href="http://docs.oracle.com/javase/6/docs/api/java/util/Deque.html" rel="nofollow">more</a>, sometimes you <a href="http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html" rel="nofollow">don't need methods at all</a>. What matters is that you can separate behavior from implementation.

blocks|key|3034978|text|在Java8中，保留单一方法接口非常有用，因为单一方法接口将允许使用闭包和“函数指针”。因此，无论何时针对单个方法接口编写代码，客户端代码都可以提交闭包或方法(必须具有与单个方法接口中声明的方法兼容的签名)，而不必创建匿名类。相反，如果您使用多个方法创建一个接口，则客户端代码将不会有这种可能性。它必须始终使用实现接口的所有方法的类。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3034979|因此，通常可以这样说:如果只向客户端代码公开单个方法的类可能对某些客户端有用，那么对该方法使用单个方法接口是一个好主意。一个相反的例子是Iterator接口:在这里，只有next()方法而没有hasNext()方法是没有用的。因为只实现这些方法中的一个的类是没有用的，所以在这里拆分这个接口不是一个好主意。|offset|length|style|CODE|3034980|示例：|3034981|interface+SingleMethod{+//The+single+method+interface
++++void+foo(int+i);
}

class+X+implements+SingleMethod+{+//A+class+implementing+it+(and+probably+other+ones)
++++void+foo(int+i){...}
}

class+Y+{+//An+unrelated+class+that+has+methods+with+matching+signature
++++void+bar(int+i){...}
++++static+void+bar2(int+i){...}
}

class+Framework{+//+A+framework+that+uses+the+interface
++++//Takes+a+single+method+object+and+does+something+with+it
++++//(probably+invoking+the+method)
++++void+consume(SingleMethod+m){...}
}

class+Client{+//Client+code+that+uses+the+framework
++++Framework+f+=+...;
++++X+x+=+new+X();
++++Y+y+=+new+Y();
++++f.consume(x);+//Fine,+also+in+Java+7

++++//Java+8
++++//ALL+these+calls+are+only+possible+since+SingleMethod+has+only+ONE+method!
++++f.consume(y::bar);+//Simply+hand+in+a+method.+Object+y+is+bound+implicitly
++++f.consume(Y::bar2);+//Static+methods+are+fine,+too
++++f.consume(i+->+{+System.out.println(i);+})+//lambda+expression.+Super+concise.

++++//This+is+the+only+way+if+the+interface+has+MORE+THAN+ONE+method:
++++//Calling+Y.bar2+Without+that+closure+stuff+(super+verbose)
++++f.consume(new+SingleMethod(){
+++++++++@Override+void+foo(int+i){+Y.bar2(i);+}
++++});
}|code-block|syntax|javascript|3034982|entityMap^0|0|1W|8|2D|6|2O|9|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@$D|S|E|T|F|G]|$D|U|E|V|F|G]|$D|W|E|X|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|Y|8|@]|9|@]|A|$]]|$1|J|3|K|5|L|7|Z|8|@]|9|@]|A|$M|N]]|$1|O|3|-4|5|6|7|10|8|@]|9|@]|A|$]]]|P|$]]

With Java 8, keeping the single method interface is quite useful, since single method interfaces will allow the usage of closures and "function pointers". So, whenever your code is written against a single method interface, the client code may hand in a closure or a method (which must have a compatible signature to the method declared in the single method interface) instead of having to create an anonymous class. In contrast, if you make one interface with more than one method, the client code will not have that possibility. It must always use a class that implements all methods of the interface.

So as a common guideline, one can say: If a class that only exposes a single method to the client code might be useful to some client, then using a single method interface for that method is a good idea. A counter example to this is the <code>Iterator</code> interface: Here, it would not be useful having only a <code>next()</code> method without a <code>hasNext()</code> method. Since having a class that only implements one of these methods is no use, splitting this interface is not a good idea here.

Example:

<pre><code>interface SingleMethod{ //The single method interface
 void foo(int i);
}

class X implements SingleMethod { //A class implementing it (and probably other ones)
 void foo(int i){...}
}

class Y { //An unrelated class that has methods with matching signature
 void bar(int i){...}
 static void bar2(int i){...}
}

class Framework{ // A framework that uses the interface
 //Takes a single method object and does something with it
 //(probably invoking the method)
 void consume(SingleMethod m){...}
}

class Client{ //Client code that uses the framework
 Framework f = ...;
 X x = new X();
 Y y = new Y();
 f.consume(x); //Fine, also in Java 7

 //Java 8
 //ALL these calls are only possible since SingleMethod has only ONE method!
 f.consume(y::bar); //Simply hand in a method. Object y is bound implicitly
 f.consume(Y::bar2); //Static methods are fine, too
 f.consume(i -&gt; { System.out.println(i); }) //lambda expression. Super concise.

 //This is the only way if the interface has MORE THAN ONE method:
 //Calling Y.bar2 Without that closure stuff (super verbose)
 f.consume(new SingleMethod(){
 @Override void foo(int i){ Y.bar2(i); }
 });
}
</code></pre>

blocks|key|3034996|text|Head+First+Design+Pattern一书中的Favor+Composition+over+Inheritance教程推荐使用这种方法来动态地向类添加功能。让我们来看下面的案例：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3034997|public+interface+Quackable+{
+++public+void+quack();
}+

public+class+Quacks+implements+Quackable+{
+++public+void+quack(){
+++++++//quack+behavior
+++}
}

public+class+DontQuack+implements+Quackable+{
+++++public+void+quack(){
+++++++++//dont+quack
++++}
}

public+class+QuackableDuck{
++++Quackable+quack;++//add+behavior+dynamicall

}|code-block|syntax|javascript|3034998|因此QuackableDuck类可以动态添加特性。|3034999|+++quack+=+new+Quacks();
+++//or+
+++quack+=+new+DontQuack();|3035000|因此，类似地，您可以动态地向类添加多个行为。|3035001|entityMap^0|0|P|T|Y|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@$9|T|A|U|B|C]|$9|V|A|W|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|X|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|Y|8|@]|D|@]|E|$]]|$1|M|3|N|5|H|7|Z|8|@]|D|@]|E|$I|J]]|$1|O|3|P|5|6|7|10|8|@]|D|@]|E|$]]|$1|Q|3|-4|5|6|7|11|8|@]|D|@]|E|$]]]|R|$]]

<code>Favor Composition over Inheritance</code> tutorial of <code>Head First Design Pattern</code> book recommends this approach to add functionality dynamically to a class. Let's take below case:

<pre><code>public interface Quackable {
 public void quack();
} 

public class Quacks implements Quackable {
 public void quack(){
 //quack behavior
 }
}

public class DontQuack implements Quackable {
 public void quack(){
 //dont quack
 }
}

public class QuackableDuck{
 Quackable quack; //add behavior dynamicall

}
</code></pre>

So QuackableDuck class can add feature dynamically.

<pre><code> quack = new Quacks();
 //or 
 quack = new DontQuack();
</code></pre>

So similarly you can add multiple behavior to the class dynamically.

blocks|key|195746|text|您不是根据接口中的方法数量创建接口，而是定义系统组件所期望的行为，以便将单个责任传递给它们的邻居。如果您遵循这个简单的原则/规则，您可能会也可能不会最终使用单个方法接口，这取决于您正在定义的职责。我喜欢让测试变得愚蠢、简单，并且应用程序非常灵活，所以我通常会有很多这样的测试。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|195747|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

You create interfaces not according to the number of methods in it but to define behaviour expected by components of your systems to deliver a single responsibility to their neighbors. If you follow this simple principle/rule, you might or might not end up with single method interfaces, depending on the responsibility you are defining. I like to keep tests stupid simple and the application very flexible so I usually have many of those

I have seen in many libraries like <code>Spring</code> which use a lot of interfaces with single methods in them like <code>BeanNameAware</code>, etc. 

And the implementer class will implement many interfaces with single methods.

In what scenarios does it make sense to keep single method interfaces? Is it done to avoid making one single interface bulky for example <code>ResultSet</code>? Or is there some design standard which advocates the use of these type of interfaces?

When to use Single method Interfaces in Java

Android

Java

我在很多像Spring这样的库中看到过，它们使用了很多带有单一方法的接口，比如BeanNameAware等。而实现者类将使用单个方法实现多个接口。在什么情况下，保留单一方法接口是有意义的？这样做是为了避免让单个接口变得笨重吗，比如ResultSet？或者，是否有一些设计标准提倡使用这些类型的接口？

问何时在Java中使用单方法接口
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问何时在Java中使用单方法接口EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问何时在Java中使用单方法接口
EN