我想问一个关于facade模式的问题 about golang-design-pattern HOT 4 CLOSED

倒不是不能用结构体，只是因为我个人的一些设计上的考虑。

这里用结构体或接口，对于外观模式而言是都可以的。

外观模式主要考虑对外隐藏内部api细节从而降低使用难度以及封装内部接口的变化。

既然有假设内部api会变化，直接对内部api做一层抽象作为接口使用的情况会多一些。

而且对于golang这种函数作为一等公民的语言来说，API的成员可能不仅仅是接口或类，也有可能是函数型变量。这也是我在实际开发中用过的。

总归来说，24种设计模式仅仅是一些从常见的设计中抽象出来并命名的模式。实际应用当中是这些模式互相结合，甚至创造新模式，来让代码更符合自己的场景。

以上是我个人的一点点见解。

from golang-design-pattern.

倒不是不能用结构体，只是因为我个人的一些设计上的考虑。

这里用结构体或接口，对于外观模式而言是都可以的。

外观模式主要考虑对外隐藏内部api细节从而降低使用难度以及封装内部接口的变化。

既然有假设内部api会变化，直接对内部api做一层抽象作为接口使用的情况会多一些。

而且对于golang这种函数作为一等公民的语言来说，API的成员可能不仅仅是接口或类，也有可能是函数型变量。这也是我在实际开发中用过的。

总归来说，24种设计模式仅仅是一些从常见的设计中抽象出来并命名的模式。实际应用当中是这些模式互相结合，甚至创造新模式，来让代码更符合自己的场景。

以上是我个人的一点点见解。

感觉桥接模式和适配器模式是一样的呀。具体有什么区别呀 搜了一下感觉网上说的也是模棱二可

from golang-design-pattern.

感觉桥接模式和适配器模式是一样的呀。具体有什么区别呀 搜了一下感觉网上说的也是模棱二可

主要是一些应用场景下的区别。

适配器模式是假设你有一个有一个模块A，需要使用接口IfaceA，同时拥有模块B提供模块A所需的功能，但是提供的接口为IfaceB。在不改变这两个模块代码的情况下，使用一个适配器讲IfaceB适配到IfaceA。举个形象点的例子。 你有一台显示器，用DP接口，有一个主机用HDMI接口。在不改变这两个硬件的情况下加一个转换器（适配器）让这两个设备能一起工作。

桥接模式是当需要设计的类通过两个或两个以上纬度变化的时候，分离抽象部分和实现部分，可以独立变化增加不影响其他部分。比如此项目的例子中消息类型：有紧急、和正常，有可能后续追加其他类型，非常紧急、通知等。有发送方式：短信、邮件，可能扩展其他方式：微信、电话等。这时候将抽象部分（消息类型）和实现部分（发送方式）进行分离。抽象部分保留对实现部分的引用。使用的时候进行动态组合。

from golang-design-pattern.

感觉桥接模式和适配器模式是一样的呀。具体有什么区别呀 搜了一下感觉网上说的也是模棱二可

主要是一些应用场景下的区别。

适配器模式是假设你有一个有一个模块A，需要使用接口IfaceA，同时拥有模块B提供模块A所需的功能，但是提供的接口为IfaceB。在不改变这两个模块代码的情况下，使用一个适配器讲IfaceB适配到IfaceA。举个形象点的例子。 你有一台显示器，用DP接口，有一个主机用HDMI接口。在不改变这两个硬件的情况下加一个转换器（适配器）让这两个设备能一起工作。

桥接模式是当需要设计的类通过两个或两个以上纬度变化的时候，分离抽象部分和实现部分，可以独立变化增加不影响其他部分。比如此项目的例子中消息类型：有紧急、和正常，有可能后续追加其他类型，非常紧急、通知等。有发送方式：短信、邮件，可能扩展其他方式：微信、电话等。这时候将抽象部分（消息类型）和实现部分（发送方式）进行分离。抽象部分保留对实现部分的引用。使用的时候进行动态组合。

多谢回复，感觉适配器模式更加耦合 定制化 桥接模式比较抽象,然后动态组合

from golang-design-pattern.