Unlimited WordPress themes, graphics, videos & courses! Unlimited asset downloads! From $16.50/m
Js design 1
  • Overview
  • Transcript

3.2 The Strategy Pattern

The Strategy pattern allows us to follow a different code path, or strategy, at run-time depending on the input data.

3.2 The Strategy Pattern

Hi, folks. In this lesson, we're going to take a look at the strategy pattern. The purpose of the strategy pattern is to allow a particular behavior to be selected at run time based on input data or other conditions at the time. The different behaviors that a module can use are the different strategies that may be selected at run time. This pattern is very easy to implement in JavaScript, but it's not as common as say, the pub/sub pattern that we looked at in the last lesson. This pattern is useful when we have a lot of similar related submodules that vary slightly in their behavior and we don't know which behavior we're going to need beforehand. A great practice in software development is to encapsulate variation. So whenever we have variation we should think about whether this pattern would be suitable. For the example implementation of this pattern, let's add a validator that uses different validation strategies depending on what needs to be validated. So first of all, let's create a new directory in our JS directory called strategy. And then inside this let's add a new module called strategy JS. The strategy module needs to expose a way for a strategy to be selected, and for a method on the selected strategy, often referred to as a concrete strategy, to be invoked. The individual concrete strategies will also need to invoke this method. So first let's define our validator object. I'm going to refer to this as the main validator and the strategies validators as sub validators. Just so we're clear. We can add a select validator method that allows the sub validator to be selected. This method will receive the sub validator as an argument, and can set it as a property on the main validator. As we don't specifically need to return anything from this method, we can then return the main validator to enable chaining. Next, we can add a simple validate method that will mostly just invoke the sub validators method of the same name. This method receives the value to validate as an argument. What we really need to do inside the method is make sure a validator has been selected before we try to use it. If there isn't a validator, we can just throw a simple error. Lastly, this module can return its constructor. So now we can add some new modules for the sub validators. Let's start with a telephone number validator. We can create a new file called TelValidator. And this module will need to return a validate method. This method receives the value to validate as an argument, so inside the method let's just validate that it's a number which is 11 digits long, which is how numbers are formatted, mostly in the UK where I'm from. In real life, a proper telephone number validator would be much more complex. But I'm trying to keep it simple so that we can focus on the pattern rather than the implementation. So let's have one more validator. Say, an email validator. We can have a new file called email validator. And this will also need to return a validate method. And this method will also receive the value to validate and this time let's just validate that it's a string which has the @ symbol inside it somewhere. Once again the test here is intentionally simple. Please don't use this to validate e-mail addresses in production code. So we should now be ready for our strategies to do some validation. Let's add the init module for this example so that it loads all of our new modules. So we can create a new validator by invoking the strategy constructor. And we can then select a validator and invoke its validate method. So that's a ten digit number. This just updates the main JS file so that we can load our example and we can then see whether our validator is working. And let's go to the browser now and see if everything's working. So we've got an error there in our init file, let's just take a look at that. And we just need to capsulize the reference to the strategy, so let's try that one more time. And you can see that it has correctly validated the telephone number as not being 11 digits long. Let's just go back and add one more digit. So that should be telling us that it's true. Could be a problem with the regular expression. Pretty sure that should work as expected. Let's just make sure the value is being passed through correctly, and it looks like JavaScript is automatically ignoring the first number. So let's just add one more number to the end of the number, and then the validation should pass. Great. Okay, so phone number validation is working as we expect. Once the telephone validator has been selected, we can continue to validate numbers if we wish but if we want to validate emails now we just need to select the email validator instead. And because it doesn't have an @ symbol this time the string is not recognized as an e-mail address. So the beauty of this pattern is that the main strategy doesn't know anything about any of the underlying concrete strategies. And the concrete strategies don't know anything about each other. This makes it very easy to add new strategies in the future as soon as new requirements emerge. Without having to modify the strategy or any of the existing concrete strategies. So in this lesson we looked at the strategy pattern. We learned that this pattern allows us to select a particular code path at run time. We saw how to use the pattern to create a simple validation objects that allows a consumer to specify the type of validator to use, which then performs some simple validation. Thanks for watching.

Back to the top
Continue watching with Elements