Die Vorteile eines Technique Patterns werden erkennbar, wenn man die Perspektive eines Programmierers und Systemadministrators einnimmt. Generell führt die Zerlegung in autonome Module und Klassen zu einer besseren Strukturierung des Programmcodes. In den abgegrenzten Teilbereichen hat es der Programmierer unserer Beispiel-App mit schlankeren Code-Segmenten zu tun. So lässt sich der Umfang der Navigator-Klasse durch die Auslagerung der Strategien verringern, und auf eine Bildung von Unterklassen kann im Bereich des Kontextes verzichtet werden.
Da im schlankeren und sauber abgegrenzten Code die internen Abhängigkeiten von Segmenten im Rahmen bleiben, haben Änderungen geringere Auswirkungen. Sie ziehen additionally seltener weitere – möglicherweise langwierige – Umprogrammierungen nach sich; teils können diese sogar ganz ausgeschlossen werden. Übersichtlichere Code-Segmente lassen sich auch langfristig besser pflegen, zudem werden die Problemdiagnose und die Fehlersuche erleichtert.
Darüber hinaus profitiert die Bedienung, da die Beispiel-App mit einer benutzerfreundlichen Oberfläche ausgestattet werden kann. Über deren Schaltflächen können Anwender das Programmverhalten (Routenberechnung) auf einfache Weise variabel steuern und bequem zwischen Optionen auswählen.
Da der Context der Navigations-App durch die Kapselung der Algorithmen nur mit einer Schnittstelle interagiert, ist er unabhängig von der konkreten Implementierung einzelner Algorithmen. Werden zu einem späteren Zeitpunkt die Algorithmen geändert oder neue Strategien eingeführt, muss der Code des Contexts nicht geändert werden. So könnte man die Routenberechnung schnell und unkompliziert mit zusätzlichen ConcreteStrategies für Flugzeugrouten, Schiffs- und Fernverkehr ergänzen. Die neuen Strategien müssen lediglich das Technique-Interface korrekt implementieren.
Technique Patterns erleichtern die ohnehin schon schwierige Programmierung objektorientierter Software program durch eine weitere constructive Eigenschaft. Sie ermöglichen den Entwurf mehrfach- und wiederverwendbarer Software program(-Module), deren Entwicklung als besonders anspruchsvoll gilt. So könnten auch verwandte Context-Klassen die ausgelagerten Strategien zur Routenberechnung by way of Interface nutzen und müssen sie nicht mehr selbst implementieren.
Trotz der zahlreichen Vorteile hat das Technique Sample auch einige Nachteile. Der Software program-Entwurf erzeugt durch seinen komplexeren Aufbau möglicherweise Redundanzen und Ineffizienzen in der internen Kommunikation. So kann die generische Technique-Schnittstelle, die ja alle Algorithmen gleichermaßen implementieren müssen, im Einzelfall überdimensioniert sein.
Ein Beispiel: Nachdem der Context gewisse Parameter erstellt und initialisiert hat, übergibt er sie an die generische Schnittstelle und die darin definierte Methode. Die letztlich implementierte Strategie benötigt aber nicht unbedingt alle kommunizierten Context-Parameter und verarbeitet sie demzufolge auch nicht. Eine bereitgestellte Schnittstellewird im Technique Sample additionally nicht immer optimum genutzt und ein erhöhter Kommunikationsaufwand mit überflüssigen Datentransfers lässt sich nicht immer vermeiden.
Bei der Implementierung gibt es zudem eine enge interne Abhängigkeit zwischen Consumer und Strategien. Da der Consumer die Auswahl trifft und die konkrete Strategie per Auslösebefehl anfordert (in unserem Beispiel die Berechnung der Fußgängerroute), muss er die ConcreteStrategies kennen. Man sollte daher dieses Entwurfsmuster nur verwenden, wenn Strategie- und Verhaltenswechsel wichtig bzw. elementar für die Verwendung und die Funktionsweise einer Software program sind.
Die aufgeführten Nachteile können teilweise umgangen oder ausgeglichen werden. So wird die Zahl der Objektinstanzen, die im Technique Sample in größerer Zahl anfallen können, häufig durch eine Implementierung in ein Flyweight Sample reduziert. Die Maßnahme wirkt sich auch positiv auf die Effizienz und den Speicherbedarf einer Anwendung aus.