Java implements active object ideas

We've been talking about concurrent programming, we only know that JDK5 has a concurrent programming package to help us encapsulate the complex processing mechanism under multi-threading, this article is not the focus of its underlying implementation principle, just want to say and contract the programming mode of thinking, I have been thinking of where this idea comes from, The benefits of object-oriented programming should be to summarize a pattern, only to define the pattern to understand the pattern, we usually better understand some of the complex programming, this is the process of abstraction to the theory of it! Our predecessors used these programming ideas as a theory to abstract the concept of a pattern, Is it convenient for us to better understand and accept the idea of programming? Not only that, in the current open source in full swing, how do we communicate through the code? How can we better read People's code, better understand the intentions of others, I think this and the pattern is inseparable, only so that inseparable, is because I think, with the predecessors of the abstract summary, we write some complex code, there will be some similar ideas, two and this idea, is not the design mode? We're going to think about what kind of feature to use in order to get more people to understand our intentions, to understand how I designed this system to write this piece of code. Read the design pattern you'll find that when you look at a system written by someone else, you can see at a glance what the directionality of reading the system code is. Say so much, as if the topic of my blog is not related to, in fact, not, I want to say, we are usually using Java packaged in the concurrent programming package, whether to think why so encapsulation? What are the benefits of this encapsulation? Then, the concept of design patterns comes out, yes, and I want to illustrate what design patterns are based on the design ideas that Java concurrent programming uses.

Active object mode, do not know whether we have heard that, it seems that is not one of our common OO23 design patterns, we want to say the structure of this mode:

In Active Object mode, there are mainly the following types of participants:

• Proxy: The proxy is the public interface for the caller as defined by the Active Object. At run time, the agent runs in the context of the caller thread, is responsible for translating the caller's method call into the corresponding method request, and inserts it into the corresponding Activation List, which is then returned to the caller's future object.

• Method Request: The method request defines the context information required for the execution of the method, such as calling parameters.

• Activation List: is responsible for storing all the method requests created by the agent waiting to be executed. From the runtime, the Activation list is accessed concurrently by both the caller thread and its Active Object thread, so the Activation list implementation should be thread-safe.

• Dispatcher (Scheduler): The dispatcher runs in the Active Object thread, the dispatcher decides on the next execution of the method request, and the scheduling policy can be based on a number of criteria, such as the sequential FIFO or LIFO that is inserted according to the method request, such as the priority of the method request and so on.

• Servant:servant defines the behavior and state of the active Object, which is the fact implementation of the interface defined by the Proxy.

• Future: The caller invokes the method defined by Proxy to obtain the future object. The caller can obtain the final result of the method execution from the future object. In a real implementation, the future object retains a private space to store the results of the Servant method execution.

We can look at the Java Executor framework from the point of view of the Active Object design pattern. The Java Executor Framework simplifies the division of roles in Active Object, centered on tasks (Task). As you can see, the Java Executor task that implements the Runnable or callable interface consolidates the role of method Request and Servant by implementing the run () or call () method to implement the application logic. The Java Executor Framework does not explicitly define a Proxy interface, but instead calls the Executor commit task directly, where Executor is equivalent to the dispatcher role in Active Object. From the caller's point of view, this does not look like a normal object method being called, but rather a task is submitted to Executor. So, at this level, the underlying details of concurrency have been exposed to the caller. For Java developers, Java's Executor framework is a good choice if you don't worry about the underlying concurrency details being exposed directly to the caller, or that your app doesn't need to treat concurrent objects like normal objects. Conversely, if you want to hide such concurrency details and want to manipulate concurrent objects like normal objects, you need to follow the active object design principles to clearly define the individual roles and implement your own active object mode as described in the previous section of this article.

In summary, the Java Executor Framework simplifies the schema defined by active object, blurring the division of roles in active object, which is based on the producer/consumer model, where producers and consumers work together based on tasks.

This article is from the "Chen Yanxi" blog, make sure to keep this source http://chenyanxi.blog.51cto.com/4599355/1584591

Java implements active object ideas