Using interceptors skillfully: efficient extension point design

When designing a framework recently, you need to design a class of extensibility points that you cannot simply inherit or use events to provide the user with an API. Finally, the design of the API is solved by using interceptor mode.

Extension Point Usage scenarios

The usage scenario for this extension point is as follows:

1. You cannot use inheritance, and you need to extend the types outside of the inheritance system of the type (subclasses of non-extended types).
2. You need to be able to extend new logic before and after the execution of basic logic, and even replace the underlying logic with new logic.
3. For performance-sensitive. Since the underlying logic is the core code, it is necessary to minimize the additional performance consumption of the extensibility points and to produce as few additional objects as possible.

extension point design scheme selection

In the framework design, the extension point design is mainly provided by several types of APIs: virtual methods, events, interfaces. (For details on the design of the extension point, see: The Framework Design Guidelines 2nd Edition, chapter Sixth, extensibility.) The most commonly used and most user-friendly extension points are the top two: virtual methods and events.

The main differences between the first two extension point design scenarios are:

1. Scenario: Virtual methods in inheritance are mainly provided for the extension of subtypes of types, whereas events are mainly provided for extending the behavior of types within the inheritance system for types outside of the inheritance system;
2. Control system: When a subclass overrides a virtual method, it can write its own extension code before and after the basic method of the base class, as well as control whether the method of the base class needs to be called, and the event to implement these functions requires a pre-logical event (invoking), a post-logical event (invoked), and a similar Canceleventargs.iscancel attributes, and so on, to control whether basic logic needs to be performed.
3. Performance: The call to the virtual method is very efficient and does not produce additional objects. The nature of the event mechanism is the delegate list, which iterates through the list for invocation and requires additional delegate objects, and secondly, because the. NET event is often designed to provide an event argument object inherited from the EventArgs type, which is constructed and passed on each invocation, This will also produce additional object pressure.

It can be seen that if you want to design a class of extension points that extend to the outer types of the inheritance system, neither the virtual method nor the event API is appropriate. Then we can only think of a third way: interface. The design of the interface is very flexible, but in fact, the scenario I described above is often encountered, so we should extract a class of design patterns. After some thought, I found that the interceptor pattern is better suited to this scenario. The Interceptor mode itself focuses on the interception of messages and methods, and is an extension method outside of the inheritance system, and is widely used in the implementation of AOP. With this pattern in place, we pay more attention to the extension mechanism before and after the real core method invocation, the blocking mechanism of the core method, and the form provided by the final extension API.

Implement

When the pattern is placed in Rafy to implement the extension point at commit time, the class diagram is as follows:

The use of extension points is also relatively simple, the user inherits the interceptor, writing the appropriate extension logic:

There is one detail to note: As you can see, the first parameter of the method is also a custom parameter type Submitargs. However, since the interceptor is a chain call, this type can take a value type; When this method is called heavily, there is not a large number of redundant objects compared to the extended mechanism of the event.

Add the following code to the list of saved interceptors when you start the device:

Summary

Interceptor mode is relatively simple to implement, the structure of the pattern is very similar to GOF in the responsibility chain mode, but the focus is different. When used as an extension point, it is easier for the consumer to use, and the performance is better than the event mechanism, so it can be used as a common extension point design scheme.

Using interceptors skillfully: efficient extension point design