The advantages of a strategy pattern become clear when you consider the perspective of a programmer and system administrator. In general, the breakdown into autonomous modules and classes leads to an improved structure of the program code. Programmers of our example app work with more streamlined code segments in the encapsulated sections. This allows the size of the navigator class to be reduced by outsourcing strategies, and forming subclasses is unnecessary in the Context area.
Since the internal dependencies of segments stay within reasonable limits in the leaner and neatly segregated code, changes have fewer implications. Subsequent, often time-consuming reprogramming is not required as often and may even be eliminated altogether. Clearer code segments can also be maintained better in the long-term, while troubleshooting and diagnostics are simplified.
The controls benefit too since the example app can be equipped with a user-friendly interface. The buttons allow users to easily control the program behaviour (route calculation) in a variable manner and conveniently choose between different options.
Since the Context of the navigation app only interacts with an interface due to the encapsulation of the algorithms, it is independent from the concrete implementation of individual algorithms. If the algorithms are changed at a later time or new strategies introduced, the Context code does not need to be changed. So, route calculation could be quickly and easily expanded with additional ConcreteStrategies for plane and ship routes as well as long-distance transport. The new strategies only need to correctly implement the Strategy interface.
Strategy patterns simplify what is generally the difficult task of programming object-based software, thanks to another advantage. They enable the design of reusable software (modules), which are considered to be particularly difficult to develop. Related Context classes could therefore also use the outsourced strategies for route calculation via an interface and would no longer need to implement these themselves.
Despite the many advantages, the strategy pattern also has some disadvantages. Due to its more complex structure, software design may result in redundancies and inefficiencies in internal communication. For instance, the generic Strategy interface, which all algorithms need to implement equally, may be oversized in individual cases.
An example: After the Context has created and initialised certain parameters, it sends them to the generic interface and the method defined there. But the most recently implemented strategy does not necessarily need all communicated Context parameters and therefore does not process them all. In other words, a provided interface is not always optimally used in the strategy pattern and increased communication with excessive data transfers cannot always be avoided.
In the case of implementation, there is also a close internal dependency between the client and strategies. Since the client makes the selection and requests the specific strategy using a trigger command (in our example, to calculate the pedestrian route), it needs to know the ConcreteStrategies. You should therefore only use this design pattern if strategy and behaviour changes are important or essential for the use and functioning of a software program.
These disadvantages can be partially circumvented or offset. For example, the number of object instances that can accrue in a large number in the strategy pattern can often be reduced by an implementation in a flyweight pattern. This measure has a positive effect on the efficiency and memory requirement of an application.