Это довольно старый вопрос, но, тем не менее, я тоже искал те же ответы, и это то, что я обнаружил.
Для шаблона состояния рассмотрим пример кнопки воспроизведения проигрывателя Medial Player. Когда мы играем, он начинает играть и информирует контекст о том, что он играет. Каждый раз, когда клиент хочет выполнить операцию воспроизведения, он проверяет текущее состояние игрока. Теперь клиент знает, что состояние объекта воспроизводится через объект контекста, поэтому он вызывает метод действий объектов состояния паузы. Часть клиента, осознающая состояние и в каком состоянии ему необходимо выполнить действие, может быть автоматизирована.
https://www.youtube.com/watch?v=e45RMc76884
https://www.tutorialspoint.com/design_pattern/state_pattern.htm
В случае паттерна «Стратегия» расположение диаграммы классов совпадает с паттерном состояния. Клиент приходит к этой договоренности, чтобы сделать какую-то операцию. То есть вместо разных состояний существуют разные алгоритмы, например, различные анализы, которые необходимо выполнить для шаблона. Здесь клиенты сообщают контексту, что он хочет сделать, какой алгоритм (определенный пользователем бизнес-алгоритм), а затем выполняет это.
https://www.tutorialspoint.com/design_pattern/strategy_pattern.htm
Оба реализуют принцип открытого закрытия, поэтому разработчик может добавлять новые состояния в шаблон состояний и новый алгоритм.
Но разница в том, что они используются, это шаблон состояния, используемый для выполнения другой логики, основанной на состоянии объекта. А в случае стратегии другая логика.