为什么说「设计模式」是通往BAT的必经之路？
Posted 蓝桥云课精选
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了为什么说「设计模式」是通往BAT的必经之路？相关的知识，希望对你有一定的参考价值。
开闭原则(Open Closed Principle，OCP) 由勃兰特.梅耶(Bertrand Meyer)提出，他在 1988 年的著作《面向对象软件构造》( Object Oriented Software Construction)中提出：软件实体应当对扩展开放，对修改关闭(Software entities should be open for extension, but closed for modification)，这就是开闭原则的经典定义。
package
main
import
"fmt"
type
ICar
interface
{
// 车名
GetName
()
string
// 价格
GetPrice
()
int
}
type
BenzCar
struct
{
name
string
price
int
}
func
(
b
BenzCar
)
GetName
()
string
{
return
b
.
name
}
func
(
b
BenzCar
)
GetPrice
()
int
{
return
b
.
price
}
func
main
()
{
var
(
list
[]
ICar
)
list
=
[]
ICar
{}
list
=
append
(
list
,
&
BenzCar
{
"迈巴赫"
,
130
})
list
=
append
(
list
,
&
BenzCar
{
"AMG"
,
343
})
list
=
append
(
list
,
&
BenzCar
{
"V"
,
60
})
for
_
,
v
:=
range
list
{
fmt
.
Println
(
"车名:"
,
v
.
GetName
(),
"\t价格:"
,
v
.
GetPrice
())
}
}
修改 ICar 接口：在 ICar 接口上加一个 getPriceWithFinance 接口，专门获取加上金融服务费后的价格信息。这样的后果是，实现类 BenzCar 也要修改，业务类 Shop4S 也要做相应调整。ICar 接口一般应该是足够稳定的，不应频繁修改，否则就失去了接口锲约性了。
修改 BenzCar 实现类：直接修改 BenzCar 类的 getPrice 方法，添加金融服务费的处理。这样的一个直接后果就是，之前依赖 getPrice 的业务模块的业务逻辑就发生了改变了，price 也不是之前的 price 了。
使用子类拓展来实现：增加子类 FinanceBenzCar，覆写父类 BenzCar 的 getPrice 方法，实现金融服务费相关逻辑处理。这样的好处是：只需要调整 Shop4S 中的静态模块区中的代码，main 中的逻辑是不用做很大的修改的。
type
FinanceBenzCar
struct
{
BenzCar
}
func
(
b
FinanceBenzCar
)
GetPrice
()
int
{
// 获取原价
selfPrice
:=
b
.
price
var
finance
int
if
selfPrice
>=
100
{
finance
=
selfPrice
+
selfPrice
*
5
/
100
}
else
if
selfPrice
>=
50
{
finance
=
selfPrice
+
selfPrice
*
2
/
100
}
else
{
finance
=
selfPrice
}
return
finance
}
func
main
()
{
var
(
list
[]
ICar
)
list
=
[]
ICar
{}
list
=
append
(
list
,
&
FinanceBenzCar
{
BenzCar
{
"迈巴赫"
,
99
}})
list
=
append
(
list
,
&
FinanceBenzCar
{
BenzCar
{
"AMG"
,
200
}})
list
=
append
(
list
,
&
FinanceBenzCar
{
BenzCar
{
"V"
,
40
}})
for
_
,
v
:=
range
list
{
fmt
.
Println
(
"车名:"
,
v
.
GetName
(),
"\t价格:"
,
v
.
GetPrice
())
}
}
=== RUN TestBenzCar_GetName
车名: 迈巴赫 价格: 100
车名: AMG 价格: 210
车名: V 价格: 40
--- PASS: TestBenzCar_GetName (0.00s)
PASS
提高代码复用性
提高代码的可维护性
单一职责可以降低类的复杂性，提高代码可读性、可维护性。
但是用“职责”或“变化原因”来衡量接口或类设计得是否优良，但是“职责”和“变化原因”都是不可度量的，因目、环境而异；指责划分稍微不当，很容易造成资源浪费，代码量增多。
package
main
import
"fmt"
type
Animal
interface
{
dance
()
}
type
Rabbit
struct
{
}
func
(
r
Rabbit
)
dance
()
{
fmt
.
Println
(
"兔子跳舞"
)
}
type
Dog
struct
{
}
func
(
d
Dog
)
dance
()
{
fmt
.
Println
(
"狗跳舞"
)
}
type
Lion
struct
{
}
func
(
l
Lion
)
dance
()
{
fmt
.
Println
(
"狮子跳舞"
)
}
type
Person
struct
{
ani
Animal
}
func
(
p
Person
)
WalkAnimal
()
{
fmt
.
Println
(
"人开始溜动物"
)
p
.
ani
.
dance
()
}
func
main
(){
person
:=
Person
{
ani
:
&
Dog
{}}
person
.
WalkAnimal
()
}
里氏替换可以提高代码复用性,子类继承父类时自然继承到了父类的属性和方法。
提高代码可拓展性，子类通过实现父类方法进行功能拓展，个性化定制。
里氏替换中的继承有侵入性。继承，就必然拥有父类的属性和方法。
增加了代码的耦合性。父类方法或属性的更改，要考虑子类所引发的变更。
❝
以上是关于为什么说「设计模式」是通往BAT的必经之路？的主要内容，如果未能解决你的问题，请参考以下文章