桥接模式是结构型设计模式,桥接模式本身应对的是由于实际的需要,使用不同纬度的条件和方法,桥接模式可以将两个类型分离出来,让两者之间都可以独立的拓展,让每一个类都更加符合单一职责。桥接模式与多层继承方案有些不太相同,它让两个独立变化的设计成为两个独立的继承等级的类,并且在抽象简历一个抽象关系,该关系类似一条连接两个继承结构的桥。
桥接模式用了一种巧妙的方式处理多层继承存在的问题,用抽象关联取代传统的多层继承关系,将类与静态继承关系转换成动态的对象组合关系,是得系统更加灵活,易于拓展,同时有效的控制系统类中类的个数。
桥接模式:桥接模式是将抽象部分与它的实现部分分离,使它们都可以独立地变化。它是一种对象结构型模式,又称为柄体(Handle and Body)模式或接口(interface)模式。 ——节选自百度百科
桥接模式通过将继承改为组合的方式来解决这个问题。具体来说,就是抽取其中一个维度并使之成为独立的类层次, 这样就可以在初始类中引用这个新层次的对象,从而使得一个类不必拥有所有的状态和行为。桥接模式主要应对的是由于实际的需要,某个类具有两个或者两个以上的维度变化,如果只是用继承将无法实现这种需要,或者使得设计变得相当臃肿。
桥接模式中的抽象部分持有具体实现部分的接口,最终目的是通过调用具体实现部分的接口中的方法,进一步完成一定的功能,这跟直接使用接口没有什么差异,只是表现形式略有不同而已。其次,使用接口的客户程序也可以持有相应的接口对象,这样从形式上就一样了。也就是说,从某个角度来讲,桥接模式是面向抽象编程这个设计原则的扩展。
正是通过具体实现的接口,把抽象部分和具体的实现分离开来,抽象部分相当于是使用实现部分接口的客户程序,这样抽象部分和实现部分就松散耦合了,从而可以实现相互独立的变化。这样一来,几乎可以把所有面向抽象编写的程序,都视作是桥接模式的体现,至少算是简化的桥接模式,就算是广义的桥接吧。
优点
可以创建与平台无关的类和程序
客户端代码仅与高层抽象部分进行互动,不会接触到平台的详细信息
新增抽象部分和实现部分之间不会互相影响
抽象部分专注于处理高层逻辑,实现部分处理平台细节
缺点
对高内聚的类使用桥接模式可能会让代码更加复杂化
桥接模式的主要角色如下:
抽象部分:提供高层控制逻辑,依赖于完成底层实际工作的实现对象
实现部分:为所有具体实现声明通用接口。抽象部分仅能通过在这里声明的方法于实现对象交互
实现具体:包括特定于平台的代码
精确抽象:提供控制逻辑的变体,与其父类一样,他们通过通用实现接口与不同的实现进行交互
客户端:仅关心如何与抽象部分合作。但是,客户端需要将抽象对象与一个实现对象连接起来
类图如下所示:
代码示例:
// 实现接口角色
interface Implementor {
doSomething() : void;
doAnything() : void;
}
// 具体实现角色
class ConcreteImplementor1 implements Implementor {
public doSomething() : void {
}
public doAnything() : void {
}
}
class ConcreteImplementor2 implements Implementor {
public doSomething() : void {
}
public doAnything() : void {
}
}
// 抽象类
abstract class Abstraction {
private imp : Implementor;
constructor(imp : Implementor) {
this.imp = imp;
}
// 自身的行为和属性
public request() : void {
this.imp.doSomething();
}
}
// 具体抽象化角色
class RefinedAbstraction extends Abstraction {
constructor(imp : Implementor) {
super(imp);
}
public request() : void {
// 自己写一些处理业务
super.request();
}
}
// 调用
// 定义一个实现化角色
const imp : Implementor = new ConcreteImplementor1();
// 定义一个抽象化角色
const abs : Abstraction = new RefinedAbstraction(imp);
// 执行上下文
abs.request();
如果一个系统需要在构建的抽象化角色和具体化角色之间增加更多的灵活性,避免在两个层次之间简历静态的继承关系,通过桥接模式可以使他们在抽象层建立关系。
抽象化角色和实现化角色可以以继承的方式独立扩展而互不影响,在程序运行时可以动态将一个抽象化子类的对象和一个实现化子类的对象进行组合,即系统需要对抽象化角色和实现化角色进行动态耦合。
单例模式是我们开发中一个非常典型的设计模式,js单例模式要保证全局只生成唯一实例,提供一个单一的访问入口,单例的对象不同于静态类,我们可以延迟单例对象的初始化,通常这种情况发生在我们需要等待加载创建单例的依赖。
工厂模式下的对象我们不能识别它的类型,由于typeof返回的都是object类型,不知道它是那个对象的实例。另外每次造人时都要创建一个独立的person的对象,会造成代码臃肿的情况。
建造者模式:是将一个复杂的对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示。工厂类模式提供的是创建单个类的模式,而建造者模式则是将各种产品集中起来进行管理,用来创建复合对象
主要涉及知识点: HTML与XHTML,HTML与XHTML的区别,DOCTYPE与DTD的概念,DTD的分类以及DOCTYPE的声明方式,标准模式(Standard Mode)和兼容模式(Quircks Mode),标准模式(Standard Mode)和兼容模式(Quircks Mode)的区别
JavaScript中常见的四种设计模式:工厂模式、单例模式、沙箱模式、发布者订阅模式
javascript 策略模式的定义是:定义一系列的算法,把它们一个个封装起来,并且使它们可以相互替换。 策略模式利用组合,委托等技术和思想,有效的避免很多if条件语句,策略模式提供了开放-封闭原则,使代码更容易理解和扩展, 策略模式中的代码可以复用。
javascript观察者模式又叫发布订阅模式,观察者模式的好处:js观察者模式支持简单的广播通信,自动通知所有已经订阅过的对象。存在一种动态关联,增加了灵活性。目标对象与观察者之间的抽象耦合关系能够单独扩展以及重用。
熟悉 Vue 的都知道 方法methods、计算属性computed、观察者watcher 在 Vue 中有着非常重要的作用,有些时候我们实现一个功能的时候可以使用它们中任何一个都是可以的
我觉得聊一下我爱用的 JavaScript 设计模式应该很有意思。我是一步一步才定下来的,经过一段时间从各种来源吸收和适应直到达到一个能提供我所需的灵活性的模式。让我给你看看概览,然后再来看它是怎么形成的
在围绕设计模式的话题中,工厂这个词频繁出现,从 简单工厂 模式到 工厂方法 模式,再到 抽象工厂 模式。工厂名称含义是制造产品的工业场所,应用在面向对象中,顺理成章地成为了比较典型的创建型模式
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!