Comments (4)
倒不是不能用结构体,只是因为我个人的一些设计上的考虑。
这里用结构体或接口,对于外观模式而言是都可以的。
外观模式主要考虑对外隐藏内部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.
Related Issues (16)
- 看了一下,就发现适配器模式都写错样例 HOT 1
- 为什么感觉原型模式多此一举啊,人为增加了系统的复杂度,能分享下看法吗 HOT 1
- 单例设计模式Singleton 是否应该改为包私有的,否者调用者也可以直接调用Singleton实例会对象。 HOT 1
- 发现typo HOT 1
- 单词拼写错了 HOT 1
- 适配器模式,不谢 HOT 1
- 对单例模式实现代码的建议 HOT 2
- 想要增加一些新的设计模式 HOT 2
- Provide a more realistic example HOT 1
- The Prototype pattern: potential type mismatches HOT 1
- 单例模式没有unlock,并发会造成死锁 HOT 1
- 单例模式中singleton结构体字段为空,多次赋值instance值是一样的
- 这里是不是写错了 HOT 1
- design pattern 21 chain_of_responsibility, implements is not right at all
- Question: did golang support decorator patten as python or java do? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from golang-design-pattern.