![]() ![]() However, there’s a slightly different approach (and it’s a bit more canonical) in which, upon receiving a request, a handler decides whether it can process it. Handlers are lined up one by one, forming a chain. Assuming the request contains the right data, all the handlers can execute their primary behavior, whether it’s authentication checks or caching. In our example with ordering systems, a handler performs the processing and then decides whether to pass the request further down the chain. Here’s the best part: a handler can decide not to pass the request further down the chain and effectively stop any further processing. The request travels along the chain until all handlers have had a chance to process it. In addition to processing a request, handlers pass the request further along the chain. Each linked handler has a field for storing a reference to the next handler in the chain. The pattern suggests that you link these handlers into a chain. The request, along with its data, is passed to this method as an argument. In our case, each check should be extracted to its own class with a single method that performs the check. Like many other behavioral design patterns, the Chain of Responsibility relies on transforming particular behaviors into stand-alone objects called handlers. You struggled with the code for a while, until one day you decided to refactor the whole thing. ![]() The system became very hard to comprehend and expensive to maintain. Worst of all, when you tried to reuse the checks to protect other components of the system, you had to duplicate some of the code since those components required some of the checks, but not all of them. Changing one check sometimes affected the others. The code of the checks, which had already looked like a mess, became more and more bloated as you added each new feature. The bigger the code grew, the messier it became. ![]() Hence, you added another check which lets the request pass through to the system only if there’s no suitable cached response. ![]() Someone else suggested that you could speed up the system by returning cached results on repeated requests containing the same data. To negate this, you promptly added a check that filters repeated failed requests coming from the same IP address. Later, somebody noticed that the system is vulnerable to brute force password cracking. So you added an extra validation step to sanitize the data in a request. One of your colleagues suggested that it’s unsafe to pass raw data straight to the ordering system. The request must pass a series of checks before the ordering system itself can handle it.ĭuring the next few months, you implemented several more of those sequential checks. However, if those credentials aren’t correct and authentication fails, there’s no reason to proceed with any other checks. The application can attempt to authenticate a user to the system whenever it receives a request that contains the user’s credentials. Also, users who have administrative permissions must have full access to all orders.Īfter a bit of planning, you realized that these checks must be performed sequentially. You want to restrict access to the system so only authenticated users can create orders. Imagine that you’re working on an online ordering system. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |