在这个例子中，我们将研究两种策略模式的实现，但它们都以稍微不同的方式实现了相同的结果。它们只是为不同的银行创建了代币。
这两种策略模式在现实世界的场景中都是有效的，所以 "重复的解决方案 "并不一定意味着它是一个糟糕的设计。这只是你如何处理这种商业案例。此外，两种模式都有其优势和劣势。
-
**所有的策略都以不同的方式处理相同的工作--**重复的解决方案，灵活的配置结构。由个别配置参数和具体策略管理。所有策略都可以有自己的配置结构。
-
**所有策略以相同的方式处理同一工作--**简单的解决方案，严格的配置结构。由配置参数管理，需要单一的具体策略。策略依赖于一种类型的配置结构。
这两个例子都依赖于请求对象中的ProviderName 参数。基于给定的值。
-
第一个模型将请求转移到使用其自身配置的相关提供商实现/包（Barclays或Natwest）。
-
第二个模型选择相关的配置并在共同的实现中使用它（access_token或refresh_token）。
所有策略都以不同的方式处理相同的工作
结构
├── main.go
文件
main.go
package main
欧比/access_token.go
package obie
欧比/provider.go
package obie
obie/barclays/config.go
package barclays
欧比/barclays/provider.go
package barclays
欧比/Natwest/config.go
package natwest
欧比/Natwest/config.go
package natwest
所有的策略都以相同的方式处理相同的工作
结构
├── main.go
文件
main.go
package main
obie/config.go
package obie
obie/client.go
package obie
欧比/access_token.go
package obie
欧比/refresh_token.go
package obie
