Design Description:
The Count agent mode is useful when the client object invokes a series of additional features, such as log (logging) and count (counting), before and after the method on the service provider object. The Count agent pattern suggests encapsulating these additional functions in a single object, which refers to the counting agent object, rather than putting these additional functionality implementations into the service provider's interior. One feature of good object design is that objects are focused on providing specific functionality. In other words, the ideal object should not do all sorts of irrelevant things. Encapsulate similar functions such as log (logging) and count (counting) into a single object, and let the service provider object provide only its own specific functionality. That is, only the service provider object is allowed to perform well-defined, specific tasks.
The Count agent is designed to be a client-accessible object with the same interface as the service provider. Instead of directly accessing the service provider, the client object is invoking the method on the Count proxy object, and the Count agent performs the necessary record log (logging) and count (counting) functions, and then passes the method call to the service providing the object. As shown in Figure 1
Figure1:generic Class Association When the counting Proxy pattern is applied
The following example shows how to use the Count proxy in an application.
Example:
Let's design an order class where the class hierarchy, like the diagram 2,orderif interface, declares an easy way to read all orders in the database getallorders.
Figure2:order Class Hierarchy
Public interface Orderif {
Public Vector getallorders ();
}
As part of the implementation of the Getallorders method, the order class is useful for the Fileutil tool class to read orders from Order.txt files.
public class Order implements Orderif {
Public Vector getallorders () {
Fileutil fileutil = new Fileutil ();
Vector v = fileutil.filetovector ("Orders.txt");
return v;
}
}
Let's assume that when you call Getallorders (), you need to take the data file to the log log file that takes the time and the number of records to be logged.
This additional function can be implemented by designing a separate Orderproxy class that implements the Orderif interface as the real object order. This ensures that the Orderproxy object provides the client with the same interface as the real object order. As shown in Figure 3
Figure3:order Class hierarchy with the counting Proxy
public class Orderproxy implements Orderif {
private int counter = 0;
Public Vector getallorders () {
Order order = New Order ();
counter++;
Long T1 = System.currenttimemillis ();
Vector v = order.getallorders ();
Long t2 = System.currenttimemillis ();
Long Timediff = t2? T1;
String msg = "iteration=" + Counter + ":: Time=" + Timediff + "MS";
Log the message
Fileutil fileutil = new Fileutil ();
Fileutil.writetofile ("Log.txt", MSG, True, true);
return v;
}
}
The client object Mainapp calls the Getallorders () method on the Orderproxy object just like calling the real object order, orderproxy the object to pass this call to the real object order, Calculates the amount of time spent reading all orders and uses the Fileutil help class to record its log log file. In this process, Orderproxy plays the role of counting agents.
public class Mainapp {
public static void Main (string[] args) {
Orderif order = new Orderproxy ();
Vector v = order.getallorders ();
v = order.getallorders ();
v = order.getallorders ();
v = order.getallorders ();
}
}
