Formal definition: The Strategy pattern defines a family of algorithms, encapsulates each one and makes them interchangeable. Strategy lets the algorithms vary independently from clients that use it.
The idea: We want to code. Albeit peacefully. We want to just put in the necessary additions and deletions using the same concepts, hit save and BAM!! Everything has to work at that point. The one thing that could come in our way is that though the overall coding nature stays the same the underlying implementations and ideas have changed. How do we make the code behave the same even though some underlying components are contradicting with our current implementations? The first thing that could come to mind is to add conditions, dirty ones. Then, we get a bit more gentle and push those conditions inside the class hideously. But what about the next iteration? No, we need something better.
Wait, why are we not letting the component decide what it wants to show? We just add a Generalization layer that allows us to use the same Client code while beyond that, the components tell what the client code shows. For example:
If you have worked with form validations, how often have you faced the problem of having inadequate information in the validation mechanism. Such as, Text input fields, Email fields, Textarea all have similar implementations that's fine. So, we can just iterate over each field, create an object of validator, run it on that field's data and done. But, what about Checkboxes? You need to check how many of them are ticked, you need only one of them ticked. What about Payment data? What if in the next iterations you need Combined field types to be validated? These changes are big and they will turn monstrous.
But if we create validators of each field types and bind their validations "Strategies" to them, then all we really need to do is check which field type we are currently checking, create a validator of that type and run that on that field. Since we also create a generalization layer it's easy to communicate which type we want the validator to have.
Example:
The idea: We want to code. Albeit peacefully. We want to just put in the necessary additions and deletions using the same concepts, hit save and BAM!! Everything has to work at that point. The one thing that could come in our way is that though the overall coding nature stays the same the underlying implementations and ideas have changed. How do we make the code behave the same even though some underlying components are contradicting with our current implementations? The first thing that could come to mind is to add conditions, dirty ones. Then, we get a bit more gentle and push those conditions inside the class hideously. But what about the next iteration? No, we need something better.
Wait, why are we not letting the component decide what it wants to show? We just add a Generalization layer that allows us to use the same Client code while beyond that, the components tell what the client code shows. For example:
If you have worked with form validations, how often have you faced the problem of having inadequate information in the validation mechanism. Such as, Text input fields, Email fields, Textarea all have similar implementations that's fine. So, we can just iterate over each field, create an object of validator, run it on that field's data and done. But, what about Checkboxes? You need to check how many of them are ticked, you need only one of them ticked. What about Payment data? What if in the next iterations you need Combined field types to be validated? These changes are big and they will turn monstrous.
But if we create validators of each field types and bind their validations "Strategies" to them, then all we really need to do is check which field type we are currently checking, create a validator of that type and run that on that field. Since we also create a generalization layer it's easy to communicate which type we want the validator to have.
Example:
