Intercepting Filter design pattern

The simplest form of this pattern is the following:

switch (condition){
     case Value1:

      case Value2:

     default:
}

Another approach to Intercepting Filter Pattern

Once a request has made it into an HttpApplication, it passes through any number of IHttpModules. Each module is independent and has only a limited amount of control over the order in which it is invoked. The HttpApplication class exposes a sequence of events that get raised as the request makes its way through processing. These events include BeginRequest, AuthenticateRequest, AuthorizeRequest, and EndRequest. When the HttpApplication loads a module, it calls the Init method of the IHttpModule interface, allowing the module to register for any of the events it cares about. As a given request is handled, the events are raised in the appropriate order and all registered modules get a chance to interact with the request. The module can therefore control the stage at which it gets invoked, but not the exact order within that stage.

These modules are an example of the Intercepting Filter pattern. This pattern represents a chain of filters that are each in turn given a chance to modify a request (or message) that passes through them. Figure  shows a simplified flow diagram of this process. The key ideas of this pattern are that the filters are independent; filters can modify the request as it passes through.

 

Figure  Request Flow  

 

There are several different implementation variations of the Intercepting Filter pattern, one of which is the event-based model employed by ASP.NET. A simpler variant involves maintaining a list of filters and iterating over it, invoking a method on each one in turn. This is how the Web Services Enhancements (WSE) for ASP.NET Web services uses this pattern. Each filter either extends SoapInputFilter (for request messages) or SoapOutputFilter (for responses), overriding the ProcessMessage method to perform the work of the filter.

Another option is to implement Intercepting Filter via the Decorator pattern. Then each filter would wrap its successor, performing preprocessing, invoking the successor, and then performing post-processing. The chain would be built using recursive composition, from back to front. This pattern is used to implement .NET Remoting channel sinks.

Regardless of implementation, the result is a dynamically configurable chain of independent filters. Since they are independent, these filters can easily be reordered and reused in other applications. Common tasks like authentication or logging can be encapsulated in a filter and used over and over. These tasks can then be handled by the filter chain before a request even reaches the HttpHandler, keeping the handler code cleaner.

Decorator Dessign Pattern
see also:Intercepting filter in java