
java开源 - 云代码空间
——

定义一系列算法,将每个算法封装起来。并让它们能够相互替换。策略模式让算法独立于使用它的客户而变化。
package main
import "fmt"
type user struct {
name string
}
func (this user) travel(t string) {
switch t {
case "飞机":
fmt.printf("%s,飞机出行\n", this.name)
case "火车":
fmt.printf("%s,火车出行\n", this.name)
case "走路":
fmt.printf("%s,走路出行\n", this.name)
default:
fmt.println("你未选择了出行方式吗")
}
}
func main() {
user{"张三"}.travel("飞机")
user{"张三"}.travel("火车")
user{"张三"}.travel("走路")
user{"张三"}.travel("")
}
问题:
代码很多且复杂,if…else…多,不利于维护和扩展违反了"开闭原则",增加新的出行方式必须修改源码复用性差,无法单独重用其中的某个或某些算法
生活策略模式例子:
张三从广东去北京【1.坐飞机,2.坐火车,3.走路】鹅厂推出了3种会员,分别为会员,超级会员、及金牌会员【皮肤不同,折扣不同】诸葛亮的锦囊妙计
策略模式涉及到三个角色:
| 编号 | 角色 | 描述 |
|---|---|---|
| 1 | 环境(context)角色 | 持有一个strategy的引用 |
| 2 | 抽象策略(strategy)角色 | 这是一个抽象角色,通常由一个接口或抽象类实现。此角色给出所有的具体策略类所需的接口 |
| 3 | 具体策略(concretestrategy)角色 | 包装了相关的算法或行为。 |

优点:
策略模式提供了对“开闭原则”的完美支持,用户可以在不修改原有系统的基础上选择算法或行为,也可以灵活地-增加新的算法或行为。提供管理相关的算法族可以替换继承关系的办法。避免使用多重条件转移语句。
缺点:
客户端必须知道所有的策略类,并自行决定使用哪一个策略类策略模式将造成产生很多策略类,可以通过使用享元模式在一定程度上减少对象的数量
package main
import "fmt"
/*出行方式*/
type itravel interface {
travel()
}
/*飞机*/
type aircraft struct{}
/*火车*/
type train struct{}
/*走路*/
type walk struct{}
/*具体策略类 1:飞机出行*/
func (this aircraft) travel() {
fmt.println("飞机出行")
}
/*具体策略类 2:火车出行*/
func (this train) travel() {
fmt.println("火车出行")
}
/*具体策略类 3:走路出行*/
func (this walk) travel() {
fmt.println("走路出行")
}
/*环境类*/
type user struct {
name string
itravel itravel
}
func (this user) travel() {
fmt.printf("%s", this.name)
this.itravel.travel()
}
func main() {
user := user{"张三", aircraft{}}
user.travel()
user = user{"李四", new(train)}
user.travel()
user = user{"王五", &walk{}}
user.travel()
}