# 桥接模式（Bridge Pattern）详解

桥接模式是经典**结构型设计模式**，核心思想是**将抽象接口与底层实现解耦，使二者可以独立扩展变化**，通过「组合关系」替代「多层继承」，从根源上解决多维度变化带来的类数量爆炸问题。

简单理解：当一个事物存在两个及以上独立变化的维度时，不要用继承把维度硬绑定在一起，而是把每个维度拆成独立的类层次，再通过一个 “桥接点” 把它们组合起来，实现任意维度的自由扩展与组合。

------

## 一、解决的核心痛点：继承导致的类爆炸

桥接模式诞生的直接原因，是**多层继承的维度爆炸问题**。我们用一个最经典的场景举例：

假设开发绘图程序，存在两个独立变化的维度：

- 形状维度：圆形、矩形、三角形（3 种）
- 颜色维度：红色、蓝色、绿色（3 种）

如果用纯继承实现，每个形状的每种颜色都要定义一个子类，总共需要 `3×3=9` 个具体类。后续每新增 1 种形状，要同步加 3 个颜色子类；每新增 1 种颜色，要同步加 3 个形状子类。维度越多，类数量呈指数级增长，代码复用性极差、维护成本极高，这就是典型的**类爆炸**。

桥接模式的解法：把形状和颜色拆成两个完全独立的类层次，形状类持有颜色类的指针（桥接点），通过组合实现搭配。新增形状只加形状类，新增颜色只加颜色类，二者完全互不影响。

------

## 二、核心结构与角色

标准桥接模式包含 4 个核心角色，通过「抽象层持有实现层引用」完成桥接：

|                  角色                  |        定位        |                             职责                             |
| :------------------------------------: | :----------------: | :----------------------------------------------------------: |
|       **抽象层（Abstraction）**        |    高层业务抽象    | 定义对外的业务接口，内部持有实现层的指针（桥接点），高层逻辑委托给实现层执行 |
| **扩展抽象层（Refined Abstraction）**  | 抽象维度的具体实现 |   继承抽象层，扩展、细化高层业务逻辑，是抽象维度的具体子类   |
|     **实现层接口（Implementor）**      | 底层能力的统一规范 |    定义底层能力的通用接口，供抽象层调用，隐藏具体实现细节    |
| **具体实现层（Concrete Implementor）** | 实现维度的具体落地 |           实现层接口的具体子类，完成真正的底层逻辑           |

> 关键认知：抽象层面向业务语义，实现层面向底层能力，二者仅通过接口交互，互不感知内部细节，因此可以各自独立扩展。

------

## 三、经典 C++ 实现示例（形状 + 颜色）

下面用「形状 - 颜色」场景给出完整的工业级 C++ 实现，全程使用智能指针管理生命周期，符合现代 C++ 规范。

桥接点是用 `protected` ，聚合关系来实现。

```cpp
#include <iostream>
#include <memory>
#include <string>

// ==============================================
// 实现层维度：颜色
// ==============================================
// 实现层接口：颜色规范
class Color {
public:
    virtual ~Color() = default;
    virtual std::string getName() const = 0;
};

// 具体实现：红色
class RedColor : public Color {
public:
    std::string getName() const override { return "红色"; }
};

// 具体实现：蓝色
class BlueColor : public Color {
public:
    std::string getName() const override { return "蓝色"; }
};

// 具体实现：绿色
class GreenColor : public Color {
public:
    std::string getName() const override { return "绿色"; }
};

// ==============================================
// 抽象层维度：形状
// ==============================================
// 抽象层：形状基类（桥接点：持有 Color 指针）
class Shape {
public:
    // 构造时注入实现层对象，完成桥接
    Shape(std::shared_ptr<Color> color) : color_(std::move(color)) {}
    virtual ~Shape() = default;

    // 高层业务接口：绘制图形
    virtual void draw() const = 0;

protected:
    std::shared_ptr<Color> color_; // 桥接点：组合实现层
};

// 扩展抽象层：圆形
class Circle : public Shape {
public:
    using Shape::Shape; // 继承基类构造函数

    void draw() const override {
        std::cout << "绘制" << color_->getName() << "的圆形" << std::endl;
    }
};

// 扩展抽象层：矩形
class Rectangle : public Shape {
public:
    using Shape::Shape;

    void draw() const override {
        std::cout << "绘制" << color_->getName() << "的矩形" << std::endl;
    }
};

// ==============================================
// 使用示例
// ==============================================
int main() {
    // 自由组合：红色圆形
    auto red = std::make_shared<RedColor>();
    std::unique_ptr<Shape> circle = std::make_unique<Circle>(red);
    circle->draw();

    // 自由组合：蓝色矩形
    auto blue = std::make_shared<BlueColor>();
    std::unique_ptr<Shape> rect = std::make_unique<Rectangle>(blue);
    rect->draw();

    // 运行时动态切换实现
    auto green = std::make_shared<GreenColor>();
    circle = std::make_unique<Circle>(green);
    circle->draw();

    return 0;
}
```

```
绘制红色的圆形
绘制蓝色的矩形
绘制绿色的圆形
```

派生类 `Circle` 如果不写 `using Shape::Shape;`，想要支持同样的构造方式，就必须手动写一遍「参数转发」：

```cpp
class Circle : public Shape {
public:
    // 手动转发：把构造参数原样传给基类构造函数
    Circle(std::shared_ptr<Color> color) : Shape(std::move(color)) {}
    // ...
};
```

加上 `using Shape::Shape;` 之后，编译器会自动为派生类生成对应的构造函数。

```cpp
class Circle : public Shape {
public:
    using Shape::Shape; // 继承基类的所有构造函数
    // ...
};
```

**它帮你省掉了「派生类构造函数只是单纯转发参数给基类」的冗余代码**，派生类越多、基类构造函数重载越多，收益越明显。

## 五、优缺点分析

### 优点

1. **彻底解耦多维度变化**：抽象与实现独立扩展，完全符合开闭原则
2. **大幅减少类数量**：避免多层继承的类爆炸，M 个抽象类 + N 个实现类，仅需 `M+N` 个类
3. **提高复用性**：同一份底层实现可以被多个抽象层复用
4. **运行时动态切换**：可以在运行时替换具体实现，灵活性极高
5. **隐藏实现细节**：客户端仅依赖抽象接口，完全感知不到底层实现

### 缺点

1. **增加架构复杂度**：需要拆分抽象层与实现层，系统结构更抽象
2. **依赖前期设计能力**：需要在设计阶段正确识别出独立的变化维度，拆分错误会适得其反

------

## 六、易混淆模式区分

### 1. 桥接模式 vs 策略模式

|   维度   |                   桥接模式                   |                    策略模式                    |
| :------: | :------------------------------------------: | :--------------------------------------------: |
| 模式类型 |                  结构型模式                  |                   行为型模式                   |
| 核心目标 | 拆分多维度的类结构，解决架构层面的解耦与扩展 | 替换单个行为的算法实现，解决逻辑层面的灵活切换 |
| 层次结构 |      两个完整的类层次，双向都可独立扩展      |         只有算法一个类层次，上下文固定         |
| 简单区分 |         两个维度都要持续扩展 → 桥接          |        一个行为有多种实现可切换 → 策略         |

### 2. 桥接模式 vs 适配器模式

|   维度   |           桥接模式           |          适配器模式          |
| :------: | :--------------------------: | :--------------------------: |
| 设计时机 | 前期架构设计阶段主动做的解耦 | 后期兼容阶段被动做的接口适配 |
| 核心目标 |      让两个维度独立扩展      |  让不兼容的接口可以协同工作  |
| 设计思路 |          拆分与解耦          |          兼容与转换          |

------

## 七、适用场景

1. 一个类存在两个及以上独立变化的维度，且每个维度都需要独立扩展
2. 不希望使用继承，或多层继承会导致类数量爆炸
3. 需要在运行时动态切换不同的底层实现
4. 希望对客户端完全隐藏底层实现细节，仅暴露抽象接口



---

# C\+\+ 桥接模式详解

桥接模式（Bridge Pattern）是**结构型设计模式**的核心模式之一，核心思想是**将抽象与实现解耦，使二者可以独立变化**，通过组合替代继承来处理多维度的变化，从根本上解决继承带来的 “类爆炸” 问题。它也是 C\+\+ 中 Pimpl（指针实现）惯用法的理论基础。

## 一、核心思想与解决的问题

### 1\. 类爆炸困境

当系统存在**两个及以上独立变化的维度**时，如果使用继承来实现组合，子类数量会是各维度数量的乘积，导致类数量指数级膨胀。

举个典型场景：

- 维度 1（抽象层）：形状 → 圆形、矩形、三角形（3 种）

- 维度 2（实现层）：渲染 API → OpenGL、DirectX、Vulkan（3 种）

如果用继承实现所有组合，总共需要 3×3=9 个子类。每新增一种形状或渲染 API，都要新增大量子类，维护成本极高，且代码严重重复。

### 2\. 桥接的解法

桥接模式将多个变化维度拆分，让每个维度独立演化，维度之间通过**组合关系**连接（而非继承）：

- 抽象层：定义业务抽象接口，持有一个实现层的指针（这就是 “桥”）

- 实现层：定义底层实现的统一接口，提供具体的底层能力

抽象层不直接依赖具体实现，只依赖实现接口，从而实现两个维度的独立扩展。新增形状不用修改渲染代码，新增渲染 API 也不用修改形状代码。

### 3\. 关键概念：抽象与实现

这里的 “抽象” 和 “实现” 不是狭义的抽象类与派生类，而是两个变化维度的定位：

- **抽象**：偏向业务逻辑的高层抽象（如 “形状”“遥控器”“公共接口”）

- **实现**：偏向底层能力的具体实现（如 “渲染 API”“设备驱动”“内部实现”）

桥接的本质是**高层业务逻辑与底层实现机制的完全解耦**。

## 二、模式角色与结构

桥接模式包含 4 个核心角色：

| 角色                                  | 作用                                              |
| ------------------------------------- | ------------------------------------------------- |
| **Abstraction（抽象类）**             | 定义高层抽象接口，内部持有实现层对象的引用 / 指针 |
| **RefinedAbstraction（扩充抽象类）**  | 抽象类的具体派生，扩展抽象层的业务逻辑            |
| **Implementor（实现类接口）**         | 定义底层实现的统一接口，供抽象层调用              |
| **ConcreteImplementor（具体实现类）** | 实现 Implementor 接口，提供具体的底层能力         |

## 三、经典 C\+\+ 实现（继承 \+ 虚函数版）

这是 GoF 定义的标准桥接模式实现，通过虚函数实现运行时多态，支持运行时动态切换具体实现。

### 示例场景

抽象层为「形状」（圆形、矩形），实现层为「渲染器」（OpenGL 渲染、DirectX 渲染），两个维度自由组合、独立扩展。

```cpp
#include <iostream>
#include <memory>
#include <string>

// 1. 实现层接口（Implementor）
class Renderer {
public:
    virtual ~Renderer() = default;
    virtual void renderCircle(double radius) const = 0;
    virtual void renderRectangle(double width, double height) const = 0;
};

// 2. 具体实现类（ConcreteImplementor）：OpenGL渲染器
class OpenGLRenderer : public Renderer {
public:
    void renderCircle(double radius) const override {
        std::cout << "[OpenGL] 绘制圆形，半径: " << radius << std::endl;
    }

    void renderRectangle(double width, double height) const override {
        std::cout << "[OpenGL] 绘制矩形，宽: " << width << " 高: " << height << std::endl;
    }
};

// 具体实现类：DirectX渲染器
class DirectXRenderer : public Renderer {
public:
    void renderCircle(double radius) const override {
        std::cout << "[DirectX] 绘制圆形，半径: " << radius << std::endl;
    }

    void renderRectangle(double width, double height) const override {
        std::cout << "[DirectX] 绘制矩形，宽: " << width << " 高: " << height << std::endl;
    }
};

// 3. 抽象层（Abstraction）
class Shape {
protected:
    // 桥接核心：持有实现层对象的指针，连接两个维度
    std::shared_ptr<Renderer> renderer;
public:
    explicit Shape(std::shared_ptr<Renderer> r) : renderer(std::move(r)) {}
    virtual ~Shape() = default;
    virtual void draw() const = 0; // 抽象业务方法
};

// 4. 扩充抽象类（RefinedAbstraction）：圆形
class Circle : public Shape {
private:
    double radius;
public:
    Circle(double r, std::shared_ptr<Renderer> rnd)
        : Shape(std::move(rnd)), radius(r) {}

    void draw() const override {
        // 业务逻辑委托给实现层完成
        renderer->renderCircle(radius);
    }
};

// 扩充抽象类：矩形
class Rectangle : public Shape {
private:
    double width, height;
public:
    Rectangle(double w, double h, std::shared_ptr<Renderer> rnd)
        : Shape(std::move(rnd)), width(w), height(h) {}

    void draw() const override {
        renderer->renderRectangle(width, height);
    }
};

// 客户端使用
int main() {
    // 创建实现层对象
    auto glRenderer = std::make_shared<OpenGLRenderer>();
    auto dxRenderer = std::make_shared<DirectXRenderer>();

    // 抽象层与实现层自由组合
    Circle glCircle(5.0, glRenderer);
    Rectangle dxRect(4.0, 6.0, dxRenderer);

    std::cout << "=== 绘制图形 ===" << std::endl;
    glCircle.draw();
    dxRect.draw();

    // 运行时切换实现：同一个形状换用不同渲染器
    Circle dxCircle(5.0, dxRenderer);
    dxCircle.draw();

    return 0;
}
```

### 输出结果

```Plain Text
=== 绘制图形 ===
[OpenGL] 绘制圆形，半径: 5
[DirectX] 绘制矩形，宽: 4 高: 6
[DirectX] 绘制圆形，半径: 5
```

**扩展性验证**：

- 新增三角形：只需新增一个 `Shape` 子类，无需修改任何渲染器代码

- 新增 Vulkan 渲染器：只需新增一个 `Renderer` 子类，无需修改任何形状代码

完全符合开闭原则，类数量从 “乘积级” 降为 “和级”。

## 四、现代 C\+\+ 实践：Pimpl 惯用法

Pimpl（Pointer to Implementation，指针实现）是桥接模式在 C\+\+ 中最广泛的工程应用，也叫 “编译防火墙”。它将类的私有实现全部隐藏在内部 Impl 类中，头文件只暴露公共接口，大幅减少编译依赖。

### 核心对应关系

- 对外的公共类 → **Abstraction（抽象层）**

- 内部的 Impl 结构体 → **Implementor（实现层）**

- 类持有的 `unique_ptr<Impl>` → 桥接指针

### 完整代码示例

**头文件：widget\.h（对外暴露）**

```cpp
#pragma once
#include <memory>
#include <string>

class Widget {
public:
    explicit Widget(std::string name);
    ~Widget(); // 必须在源文件中定义，不能直接用 =default

    // 支持移动语义（配合unique_ptr）
    Widget(Widget&&) noexcept;
    Widget& operator=(Widget&&) noexcept;

    // 公共业务接口
    void setText(const std::string& text);
    std::string getText() const;
    void render() const;

private:
    // 前向声明：实现细节完全隐藏在头文件之外
    struct Impl;
    std::unique_ptr<Impl> pImpl; // 桥接核心指针
};
```

**源文件：widget\.cpp（内部实现）**

```cpp
#include "widget.h"
#include <iostream>

// 实现类：所有私有成员、内部逻辑都放在这里
struct Widget::Impl {
    std::string name;
    std::string text;
    int fontSize = 14;

    void renderInternal() const {
        std::cout << "渲染控件: " << name 
                  << " 内容: " << text 
                  << " 字号: " << fontSize << std::endl;
    }
};

// 构造函数：创建内部Impl对象
Widget::Widget(std::string name)
    : pImpl(std::make_unique<Impl>()) {
    pImpl->name = std::move(name);
}

// 析构函数必须在源文件定义
// 原因：unique_ptr析构需要完整类型，头文件中Impl是前向声明（不完整）
Widget::~Widget() = default;
Widget::Widget(Widget&&) noexcept = default;
Widget& Widget::operator=(Widget&&) noexcept = default;

// 所有公共接口都委托给Impl实现
void Widget::setText(const std::string& text) {
    pImpl->text = text;
}

std::string Widget::getText() const {
    return pImpl->text;
}

void Widget::render() const {
    pImpl->renderInternal();
}
```

### Pimpl 的核心优势

1. **编译隔离**：修改 Impl 的私有成员、新增私有方法，不会触发依赖该头文件的代码重新编译，大幅提升大型项目编译速度

2. **隐藏实现**：用户看不到内部数据结构和私有逻辑，接口更干净，也能保护核心实现

3. **二进制兼容**：只要公共接口不变，修改 Impl 内部实现不会破坏二进制兼容性

4. **天然符合桥接思想**：接口（抽象）与实现（Impl）完全解耦，可替换不同版本的 Impl

## 五、静态桥接：模板实现（编译期多态）

如果实现层在编译期就能确定，可以用模板实现静态桥接，**完全消除虚函数调用开销**，性能更高，适合性能敏感的嵌入式、高频交易等场景。

```cpp
#include <iostream>

// 具体实现类：无需继承基类
class OpenGLRenderer {
public:
    void renderCircle(double r) const {
        std::cout << "[OpenGL] 圆形半径: " << r << std::endl;
    }
};

class DirectXRenderer {
public:
    void renderCircle(double r) const {
        std::cout << "[DirectX] 圆形半径: " << r << std::endl;
    }
};

// 抽象层：通过模板参数注入实现
template <typename Renderer>
class Circle {
private:
    double radius;
    Renderer renderer; // 编译期确定实现类型
public:
    explicit Circle(double r) : radius(r) {}

    void draw() const {
        renderer.renderCircle(radius);
    }
};

int main() {
    Circle<OpenGLRenderer> glCircle(5.0);
    Circle<DirectXRenderer> dxCircle(5.0);

    glCircle.draw();
    dxCircle.draw();
    return 0;
}
```

> C\+\+20 中可以配合 `Concept` 约束模板参数必须满足渲染接口，提供编译期类型检查，进一步提升安全性。
>
> 

特点：零运行时开销、编译期类型安全；缺点是无法在运行时切换实现。

## 六、适用场景

1. **多维度独立变化**：系统存在两个或以上独立变化的维度，且各维度都需要独立扩展

2. **避免继承类爆炸**：当继承组合会产生大量子类、代码重复严重时，桥接是最优解

3. **隐藏实现细节**：希望对外只暴露抽象接口，隐藏底层实现与私有成员（Pimpl 场景）

4. **运行时切换实现**：需要在程序运行时动态切换不同的底层实现

5. **跨平台设计**：抽象层定义通用业务逻辑，实现层适配不同操作系统、硬件或第三方库

## 七、优缺点分析

### 优点

1. **解耦性强**：抽象与实现完全分离，互不影响

2. **扩展性好**：两个维度独立扩展，新增维度元素不影响另一维度，符合开闭原则

3. **避免类爆炸**：类数量从 “乘积级” 降为 “和级”，大幅降低维护成本

4. **隐藏实现细节**：抽象层只依赖接口，用户无需关心底层实现逻辑

5. **编译优化**：Pimpl 形式可显著减少编译依赖，提升大型项目编译速度

### 缺点

1. **增加系统复杂度**：需要提前识别出独立变化的维度，架构设计难度更高

2. **初期设计成本高**：必须在架构设计阶段就拆分维度，后期重构为桥接模式成本很高

3. **轻微性能开销**：动态桥接有一次虚函数调用开销，静态桥接无此问题

4. **过度设计风险**：如果只有一个变化维度，使用桥接属于过度设计

## 八、与相似模式对比

| 模式       | 类型   | 核心目的                           | 关键区别                               |
| ---------- | ------ | ---------------------------------- | -------------------------------------- |
| 桥接模式   | 结构型 | 解耦抽象与实现两个维度，解决类爆炸 | 关注**结构拆分**，两个维度地位平等     |
| 策略模式   | 行为型 | 封装不同算法，支持运行时替换       | 关注**行为替换**，只有算法一个维度变化 |
| 适配器模式 | 结构型 | 兼容已有接口，解决接口不匹配       | 事后补救，用于兼容已有不兼容代码       |
| 装饰器模式 | 结构型 | 动态给对象添加额外功能             | 不改变原接口，只增强对象能力           |

简单区分：

- 桥接是**事前设计**，提前拆分两个独立维度

- 适配器是**事后补救**，让不兼容的接口协同工作

- 策略是**行为替换**，同一个功能的不同实现方式

## 九、总结

桥接模式的核心本质是**用组合替代继承，拆分多维度变化**，是处理 “多维度扩展” 场景的首选设计模式。

- 运行时需要动态切换实现、多维度业务复杂的场景，使用**动态桥接（虚函数版）**

- C\+\+ 工程中隐藏实现、优化编译速度，优先使用**Pimpl 惯用法**

- 性能敏感、编译期可确定实现的场景，使用**静态模板桥接**

使用的核心判断标准：**系统是否存在两个及以上独立变化的维度**。如果只有一个维度，优先用策略模式；如果维度超过两个，桥接模式同样适用，只需多层组合即可。

<!-- markdown for nginx, see https://phus.lu -->
<script>
!function(){
	var dom = {
		element: null,
		get: function (o) {
			var obj = Object.create(this)
			obj.element = (typeof o == "object") ? o : document.createElement(o)
			return obj
		},
		add: function (o) {
			var obj = dom.get(o)
			this.element.appendChild(obj.element)
			return obj
		},
		text: function (t) {
			this.element.appendChild(document.createTextNode(t))
			return this
		},
		attr: function (k, v) {
			this.element.setAttribute(k, v)
			return this
		}
	}

	if (!document.head) return
	head = dom.get(document.head)
	head.add('meta').attr('charset', 'utf-8')
	head.add('meta').attr('name', 'viewport').attr('content', 'width=device-width,initial-scale=1')

	if (!document.body) {
		document.write(["<div class=\"container\">",
		"<h3>nginx.conf</h3>",
		"<textarea rows=6 cols=50>",
		"# download markdown.html to /wwwroot",
		"location ~ \\.md$ {",
		"    default_type text/html;",
		"    add_after_body /markdown.html;",
		"}",
		"</textarea>",
		"</div>"].join("\n"))
		return
	}

	var bodytext = document.body.innerHTML
	document.body.innerHTML = ''

	div = dom.get('div').attr('class', 'container')

	div.add('script').attr('src', 'https://cdnjs.cloudflare.com/ajax/libs/marked/0.5.2/marked.min.js').attr('integrity', 'sha256-zFUosuESzULu5P+SZdjRRtBZR8+1u5RZDlbt3Q5KL8U=').attr('crossorigin', 'anonymous')
	div.add('link').attr('rel', 'stylesheet').attr('href', 'https://cdnjs.cloudflare.com/ajax/libs/github-markdown-css/5.1.0/github-markdown-light.min.css').attr('integrity', 'sha256-WQx0Y6LLZeGv3V3NVVge+YIL5MIOt45RPuFdkyNodls=').attr('crossorigin', 'anonymous')

	title = decodeURIComponent(document.location.pathname.replace(/.*\//, '').replace(/\.html$/, ''))
	document.title = '《' + title.replace(/\.md$/, '') + '》'
	tbody = div.add('table').add('tbody')
	tbody.add('tr').add('th').text(title).attr('class', 'octicon-book')
	tbody.add('tr').add('td').add('div').attr('id', 'readme').attr('class', 'markdown-body')

	wait = function (name, callback) {
		var interval = 10; // ms
		window.setTimeout(function() {
			if (window[name]) {
				callback(window[name])
			} else {
				window.setTimeout(arguments.callee, interval)
			}
		}, interval)
	}
	wait('marked', function() {
		document.getElementById("readme").innerHTML = marked.parse(bodytext)
	})

	document.body.appendChild(div.element)
}()
</script>

<style>
body {
	margin: 0;
	font-family: "ubuntu", "Tahoma", "Microsoft YaHei", Arial, Serif;
}
.markdown-body {
	float: left;
	font-family: "ubuntu", "Tahoma", "Microsoft YaHei", Arial, Serif;
}
.container {
	padding-right: 15px;
	padding-left: 15px;
	margin-right: auto;
	margin-left: auto;
}
@media (min-width: 768px) {
	.container {
		max-width: 80%;
	}
}
@media (min-width: 992px) {
	.container {
		max-width: 70%;
	}
}
@media (min-width: 1200px) {
	.container {
		max-width: 60%;
	}
}
table {
	width: 100%;
	max-width: 100%;
	margin-bottom: 20px;
	border: 1px solid #ddd;
	padding: 0;
	border-collapse: collapse;
}
table th {
	font-size: 14px;
}
table tr {
	border: 1px solid #ddd;
	padding: 5px;
}
table th, table td {
	border: 1px solid #ddd;
	font-size: 14px;
	line-height: 20px;
	padding: 3px;
	text-align: left;
}
.octicon-book {
	background-position: center left;
	background-repeat: no-repeat;
	padding-left: 20px;
	background-image: url("data:image/svg+xml;charset=utf8,%3Csvg xmlns='http://www.w3.org/2000/svg' width='16' height='16' viewBox='0 0 16 16'%3E%3Cpath d='M3,5 L7,5 L7,6 L3,6 L3,5 L3,5 Z M3,8 L7,8 L7,7 L3,7 L3,8 L3,8 Z M3,10 L7,10 L7,9 L3,9 L3,10 L3,10 Z M14,5 L10,5 L10,6 L14,6 L14,5 L14,5 Z M14,7 L10,7 L10,8 L14,8 L14,7 L14,7 Z M14,9 L10,9 L10,10 L14,10 L14,9 L14,9 Z M16,3 L16,12 C16,12.55 15.55,13 15,13 L9.5,13 L8.5,14 L7.5,13 L2,13 C1.45,13 1,12.55 1,12 L1,3 C1,2.45 1.45,2 2,2 L7.5,2 L8.5,3 L9.5,2 L15,2 C15.55,2 16,2.45 16,3 L16,3 Z M8,3.5 L7.5,3 L2,3 L2,12 L8,12 L8,3.5 L8,3.5 Z M15,3 L9.5,3 L9,3.5 L9,12 L15,12 L15,3 L15,3 Z' /%3E%3C/svg%3E");
}
</style>