blocks|key|1674448|text|基本上，它是一种模式，在这种模式中，你编写一个方法来完成总是需要的事情，例如资源分配和清理，并让调用者传入“我们想要对资源做什么”。例如：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1674449|public+interface+InputStreamAction
{
++++void+useStream(InputStream+stream)+throws+IOException;
}

//+Somewhere+else++++

public+void+executeWithFile(String+filename,+InputStreamAction+action)
++++throws+IOException
{
++++InputStream+stream+=+new+FileInputStream(filename);
++++try+{
++++++++action.useStream(stream);
++++}+finally+{
++++++++stream.close();
++++}
}

//+Calling+it
executeWithFile("filename.txt",+new+InputStreamAction()
{
++++public+void+useStream(InputStream+stream)+throws+IOException
++++{
++++++++//+Code+to+use+the+stream+goes+here
++++}
});

//+Calling+it+with+Java+8+Lambda+Expression:
executeWithFile("filename.txt",+s+->+System.out.println(s.read()));

//+Or+with+Java+8+Method+reference:
executeWithFile("filename.txt",+ClassName::methodName);|code-block|syntax|javascript|1674450|调用代码不需要担心开放/清理端-它将由executeWithFile来处理。|offset|length|style|CODE|1674451|坦率地说，这在Java语言中是痛苦的，因为闭包是如此冗长，从Java8开始，λ表达式可以像在许多其他语言中一样实现(例如，Groovy表达式，或者C#+)，并且这种特殊情况从Java7开始就使用try-with-resources和AutoClosable流来处理。|1674452|虽然“分配和清理”是一个典型的例子，但还有很多其他可能的例子--事务处理、日志记录、使用更多特权执行一些代码等。它基本上有点像template+method+pattern，但没有继承。|1674453|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Template_method_pattern^0|0|0|J|F|0|2P|I|38|C|0|1R|N|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|Z|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|10|8|@$I|11|J|12|K|L]]|9|@]|A|$]]|$1|M|3|N|5|6|7|13|8|@$I|14|J|15|K|L]|$I|16|J|17|K|L]]|9|@]|A|$]]|$1|O|3|P|5|6|7|18|8|@]|9|@$I|19|J|1A|1|1B]]|A|$]]|$1|Q|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]]|R|$S|$5|T|U|V|A|$W|X]]]]

Basically it's the pattern where you write a method to do things which are always required, e.g. resource allocation and clean-up, and make the caller pass in "what we want to do with the resource". For example:

<pre><code>public interface InputStreamAction
{
 void useStream(InputStream stream) throws IOException;
}

// Somewhere else 

public void executeWithFile(String filename, InputStreamAction action)
 throws IOException
{
 InputStream stream = new FileInputStream(filename);
 try {
 action.useStream(stream);
 } finally {
 stream.close();
 }
}

// Calling it
executeWithFile("filename.txt", new InputStreamAction()
{
 public void useStream(InputStream stream) throws IOException
 {
 // Code to use the stream goes here
 }
});

// Calling it with Java 8 Lambda Expression:
executeWithFile("filename.txt", s -&gt; System.out.println(s.read()));

// Or with Java 8 Method reference:
executeWithFile("filename.txt", ClassName::methodName);
</code></pre>

The calling code doesn't need to worry about the open/clean-up side - it will be taken care of by <code>executeWithFile</code>.

This was frankly painful in Java because closures were so wordy, starting with Java 8 lambda expressions can be implemented like in many other languages (e.g. C# lambda expressions, or Groovy), and this special case is handled since Java 7 with <code>try-with-resources</code> and <code>AutoClosable</code> streams.

Although "allocate and clean-up" is the typical example given, there are plenty of other possible examples - transaction handling, logging, executing some code with more privileges etc. It's basically a bit like the <a href="http://en.wikipedia.org/wiki/Template_method_pattern" rel="noreferrer">template method pattern</a> but without inheritance.

blocks|key|1459487|text|Execute+Around+Method是将任意代码传递给方法的地方，该方法可以执行设置和/或销毁代码，并在两者之间执行您的代码。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1459488|Java不是我用来做这件事的语言。将闭包(或lambda表达式)作为参数传递会更时髦。尽管对象可以说是equivalent+to+closures。|1459489|在我看来，围绕方法执行有点像Inversion+of+Control+(依赖注入)，您可以在每次调用该方法时进行即席更改。|1459490|但它也可以被解释为控制耦合的一个例子(通过它的参数告诉一个方法要做什么，在本例中是字面上的)。|1459491|entityMap|0|LINK|mutability|MUTABLE|url|http://c2.com/cgi/wiki?ExecuteAroundMethod|1|http://c2.com/cgi/wiki?ClosuresAndObjectsAreEquivalent|2|http://c2.com/cgi/wiki?InversionOfControl^0|0|L|0|0|1F|M|1|0|E|K|2|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@$A|W|B|X|1|Y]]|C|$]]|$1|D|3|E|5|6|7|Z|8|@]|9|@$A|10|B|11|1|12]]|C|$]]|$1|F|3|G|5|6|7|13|8|@]|9|@$A|14|B|15|1|16]]|C|$]]|$1|H|3|I|5|6|7|17|8|@]|9|@]|C|$]]|$1|J|3|-4|5|6|7|18|8|@]|9|@]|C|$]]]|K|$L|$5|M|N|O|C|$P|Q]]|R|$5|M|N|O|C|$P|S]]|T|$5|M|N|O|C|$P|U]]]]

An <a href="http://c2.com/cgi/wiki?ExecuteAroundMethod" rel="noreferrer">Execute Around Method</a> is where you pass arbitrary code to a method, which may perform setup and/or teardown code and execute your code in between.

Java isn't the language I'd choose to do this in. It's more stylish to pass a closure (or lambda expression) as the argument. Though objects are arguably <a href="http://c2.com/cgi/wiki?ClosuresAndObjectsAreEquivalent" rel="noreferrer">equivalent to closures</a>.

It seems to me that the Execute Around Method is sort of like <a href="http://c2.com/cgi/wiki?InversionOfControl" rel="noreferrer">Inversion of Control</a> (Dependency Injection) that you can vary ad hoc, every time you call the method.

But it could also be interpreted as an example of Control Coupling (telling a method what to do by its argument, literally in this case).

blocks|key|1459572|text|当你发现自己不得不做这样的事情时，就会用到执行周围的成语：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1459573|//...+chunk+of+init/preparation+code+...
task+A
//...+chunk+of+cleanup/finishing+code+...

//...+chunk+of+identical+init/preparation+code+...
task+B
//...+chunk+of+identical+cleanup/finishing+code+...

//...+chunk+of+identical+init/preparation+code+...
task+C
//...+chunk+of+identical+cleanup/finishing+code+...

//...+and+so+on.|code-block|syntax|javascript|1459574|为了避免重复“围绕”实际任务执行的所有这些冗余代码，您可以创建一个自动处理它的类：|1459575|//pseudo-code:
class+DoTask()
{
++++do(task+T)
++++{
++++++++//+..+chunk+of+prep+code
++++++++//+execute+task+T
++++++++//+..+chunk+of+cleanup+code
++++}
};

DoTask.do(task+A)
DoTask.do(task+B)
DoTask.do(task+C)|1459576|这个习惯用法将所有复杂的冗余代码移到一个地方，并使您的主程序更具可读性(和可维护性！)|1459577|看看this+post中的C#示例，以及this+article中的C%2B%2B示例。|offset|length|1459578|entityMap|0|LINK|mutability|MUTABLE|url|http://brandonbyars.com/blog/articles/2007/06/11/c-execute-around-method|1^0|0|0|0|0|0|2|9|0|K|C|1|0^^$0|@$1|2|3|4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|10|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|11|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|12|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|13|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|14|8|@]|9|@$O|15|P|16|1|17]|$O|18|P|19|1|1A]]|A|$]]|$1|Q|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]]|R|$S|$5|T|U|V|A|$W|X]]|Y|$5|T|U|V|A|$W|X]]]]

The Execute Around idiom is used when you find yourself having to do something like this:

<pre><code>//... chunk of init/preparation code ...
task A
//... chunk of cleanup/finishing code ...

//... chunk of identical init/preparation code ...
task B
//... chunk of identical cleanup/finishing code ...

//... chunk of identical init/preparation code ...
task C
//... chunk of identical cleanup/finishing code ...

//... and so on.</code></pre>

In order to avoid repeating all of this redundant code that is always executed "around" your actual tasks, you would create a class that takes care of it automatically:

<pre><code>//pseudo-code:
class DoTask()
{
 do(task T)
 {
 // .. chunk of prep code
 // execute task T
 // .. chunk of cleanup code
 }
};

DoTask.do(task A)
DoTask.do(task B)
DoTask.do(task C)</code></pre>

This idiom moves all of the complicated redundant code into one place, and leaves your main program much more readable (and maintainable!)

Take a look at <a href="http://brandonbyars.com/blog/articles/2007/06/11/c-execute-around-method" rel="noreferrer">this post</a> for a C# example, and <a href="http://brandonbyars.com/blog/articles/2007/06/11/c-execute-around-method" rel="noreferrer">this article</a> for a C++ example.

blocks|key|1674801|text|我看到这里有一个Java标记，所以我将使用Java作为示例，尽管该模式不是特定于平台的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1674802|这个想法是，有时候你的代码在你运行代码之前和之后总是涉及相同的样板。JDBC就是一个很好的例子。在运行实际查询和处理结果集之前，您总是抓取一个连接并创建一条语句(或准备好的语句)，然后总是在结束时执行相同的样板清理--关闭语句和连接。|1674803|execute-around的想法是，如果你能把样板代码去掉，那就更好了。这就省去了一些输入，但原因更深。这就是不要重复自己(DRY)原则--您将代码隔离到一个位置，以便如果有bug或需要更改它，或者您只是想了解它，那么所有代码都在一个位置。|1674804|然而，这种分解有一点棘手的是，您有“之前”和“之后”部分都需要看到的引用。在JDBC示例中，这将包括Connection和(准备好的)语句。因此，为了处理这个问题，您实际上是用样板代码“包装”了目标代码。|1674805|您可能熟悉Java中的一些常见情况。一种是servlet过滤器。另一个是围绕建议的AOP。第三个是Spring中的各种xxxTemplate类。在每种情况下，您都有一些包装器对象，您的“感兴趣的”代码(比如JDBC查询和结果集处理)被注入其中。包装器对象执行“之前”部分，调用有趣的代码，然后执行“之后”部分。|1674806|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

I see you have a Java tag here so I'll use Java as an example even though the pattern isn't platform-specific.

The idea is that sometimes you have code that always involves the same boilerplate before you run the code and after you run the code. A good example is JDBC. You always grab a connection and create a statement (or prepared statement) before running the actual query and processing the result set, and then you always do the same boilerplate cleanup at the end--closing the statement and connection.

The idea with execute-around is that it's better if you can factor out the boilerplate code. That saves you some typing, but the reason is deeper. It's the don't-repeat-yourself (DRY) principle here--you isolate the code to one location so if there's a bug or you need to change it, or you just want to understand it, it's all in one place.

The thing that's a little tricky with this kind of factoring-out though is that you have references that both the "before" and "after" parts need to see. In the JDBC example this would include the Connection and (Prepared)Statement. So to handle that you essentially "wrap" your target code with the boilerplate code.

You may be familiar with some common cases in Java. One is servlet filters. Another is AOP around advice. A third is the various xxxTemplate classes in Spring. In each case you have some wrapper object into which your "interesting" code (say the JDBC query and result set processing) is injected. The wrapper object does the "before" part, invokes the interesting code and then does the "after" part.

blocks|key|1459852|text|这让我想起了strategy+design+pattern。请注意，我所指向的链接包含该模式的Java代码。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1459853|显然，可以通过编写初始化和清理代码并传入一个策略来执行“执行”，然后该策略将始终被包装在初始化和清理代码中。|1459854|与任何用于减少代码重复的技术一样，您不应该使用它，直到您有至少2个需要它的情况，甚至可能是3个(类似于YAGNI原则)。请记住，删除代码重复会减少维护(较少的代码副本意味着在每个副本上复制修复程序所花费的时间较少)，但也会增加维护(更多的总代码)。因此，这种技巧的代价是添加了更多的代码。|1459855|这种类型的技术不仅仅用于初始化和清理。当你想要更容易的调用你的函数时，这也是很好的(例如，你可以在一个向导中使用它，这样“下一页”和“上一页”按钮就不需要巨大的case语句来决定如何转到下一页/上一页。|1459856|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/w/index.php?title=Strategy_pattern&oldid=255021999^0|6|N|0|0|0|0|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|@]|9|@]|C|$]]|$1|H|3|I|5|6|7|X|8|@]|9|@]|C|$]]|$1|J|3|-4|5|6|7|Y|8|@]|9|@]|C|$]]]|K|$L|$5|M|N|O|C|$P|Q]]]]

This reminds me of the <a href="http://en.wikipedia.org/w/index.php?title=Strategy_pattern&amp;oldid=255021999" rel="nofollow noreferrer">strategy design pattern</a>. Notice that the link I pointed to includes Java code for the pattern.

Obviously one could perform "Execute Around" by making initialization and cleanup code and just passing in a strategy, which will then always be wrapped in initialization and cleanup code.

As with any technique used to reduce code repetition, you should not use it until you have at least 2 cases where you need it, perhaps even 3 (a la the YAGNI principle). Keep in mind that the removing code repetition reduces maintenance (fewer copies of code means less time spent copying fixes across each copy), but also increases maintenance (more total code). Thus, the cost of this trick is that you are adding more code.

This type of technique is useful for more than just initialization and cleanup. It's also good for when you want to make it easier to call your functions (e.g. you could use it in a wizard so that the "next" and "previous" buttons don't need giant case statements to decide what to do to go to the next/previous page.

blocks|key|1675068|text|如果你想要时髦的习惯用法，这里有：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1675069|//--+the+target+class
class+Resource+{+
++++def+open+()+{+//+sensitive+operation+}
++++def+close+()+{+//+sensitive+operation+}
++++//--+target+method
++++def+doWork()+{+println+"working";}+}

//--+the+execute+around+code
def+static+use+(closure)+{
++++def+res+=+new+Resource();
++++try+{+
++++++++res.open();
++++++++closure(res)
++++}+finally+{
++++++++res.close();
++++}
}

//--+using+the+code
Resource.use+{+res+->+res.doWork();+}|code-block|syntax|javascript|1675070|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

If you want groovy idioms, here it is:

<pre><code>//-- the target class
class Resource { 
 def open () { // sensitive operation }
 def close () { // sensitive operation }
 //-- target method
 def doWork() { println "working";} }

//-- the execute around code
def static use (closure) {
 def res = new Resource();
 try { 
 res.open();
 closure(res)
 } finally {
 res.close();
 }
}

//-- using the code
Resource.use { res -&gt; res.doWork(); }
</code></pre>

What is this "Execute Around" idiom (or similar) I've been hearing about? 
Why might I use it, and why might I not want to use it?

What is the "Execute Around" idiom?

我听说过的这个“围绕着执行”的成语(或类似的)是什么？为什么我可以使用它，为什么我可能不想使用它？

问什么是“围绕着执行”的成语？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问什么是“围绕着执行”的成语？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问什么是“围绕着执行”的成语？
EN