参考博客：

VM虚拟机不能上网的问题解决

VM虚拟机桥接模式没法上网

VMware桥接模式无法连网问题

VMware-linux虚拟机无法使用桥接模式上网

VMware Linux 虚拟机桥接模式联网最佳配置（图文详细解说）

设备VMnet0上的网桥因桥接的以太网接口关闭而暂时停止运行

环境

VMware Workstation 12 Pro

ubuntu-18.04.2-desktop

需求描述

一开始我ubuntu使用的网络为NAT模式，这种模式能上网，但是不太喜欢在虚拟机上敲命令（因为不是很灵敏），所以我准备用xshell来连接我的ubuntu来敲命令，这是NAT就不适用了（无法访问），所以我需要把我虚拟机的网络改为桥接模式。需求很简单，按照剧本应该不用十分钟就可以搞定，但是。。。我实际操作时遇到了各种奇奇怪怪的问题，搞了几个小时，研究了半天，都没有解决，后来，我重新安装虚拟机重新来了一遍。这次，我注意了每个细节，ok了。

操作

首先我先在NAT模式下能上网的情况下，先把几个要用到的命令先安装了一下。

sudo apt-get update
sudo apt-get install net-tools
sudo apt-get install vim

然后将虚拟机调为桥接模式



调完后，我虚拟机出现了一条警告（也可以通过点击右下角的日志管理器）



如图所示的警告



如果有的话，需要打开



打开，添加网络VMnet0，然后调成桥接模式，桥接到“自动”，然后点击“应用” ->“确定”



接下来，启动虚拟机，点开网络



修改ip，网关信息，子网掩码，还有dns，除了ip地址，其他可以直接看你能上网的主机的配置信息，ip需要在同一个网段下



配置完成后，点击“应用”，然后就可以上网了。



 

目录

 

一、虚拟机网络设置无桥接模式

二、vmware 11版本 打开vm14 不兼容问题解决

三、主机为无线网络时虚拟机如何配置桥接上网

一、虚拟机网络设置无桥接模式

1.执行WIN+R

输入services.msc，打开服务管理器（回车）。

2.找到Device Install Service服务

启动此服务，默认是关闭的。

3.进入VMware-->虚拟网络编辑器

点击还原默认设置，VMware会自动卸载虚拟网卡并重装网上驱动。

4.设置VMware的网卡模式为桥接模式。

5.启动操作系统，能正常的DHCP获取“外网”IP了。

6.如果无效，直接重装！！！！（本人直接重装解决）

二、vmware 11版本 打开vm14 不兼容问题解决



分析： 

出现这种情况主要是因为虚拟机版本不一致导致的（拷贝的别人的虚拟机系统或者自己卸载重装了低版本vm）。

解决： 

根据报错信息，进入虚拟机配置文件目录，打开.vmx文件，修改版本号即可。如果你的虚拟机是vm12 就修改为12。 


三、主机为无线网络时虚拟机如何配置桥接上网

1、虚拟机选择桥接模式

2、查看主机IP，本机为192.168.191.*

3、自定义虚拟机ip为同一网段，如图

 

移动GM220S光猫超级密码及改桥接模式方法


移动GM220S光猫超级密码及改桥接模式方法
GM220S改桥接模式方法

1、使用电脑连接光猫的WIFI，再登陆光猫后台（使用光猫+路由器无法登陆时，需关闭路由器DHCP功能，具体可以百度）。

2、在【网络】【Internet连接】【宽带设置】中选择【连接名称】下拉框中第二个选项(含有INTERNET)，截图保存一下，防止桥接失败恢复原设置不知如何填写。其实主要是记录VLAN ID后面的数字、用户名、密码（一般是手机号前三位+后三位 ，如果不知道可登陆移动营业厅或10086查询）。

3、删除上面哪个含“INTERNET”的配置，然后选择【新建WAN连接】，IP协议版本选【IPV4/IPV6】，模式选【Bridge或桥模式】，端口绑定可全选，业务模式选【internet】，VLAN模式 选【改写tag】，VLAN ID填入之前记录的数字，最后点击创建保存。


4、登陆路由器后台，填入宽带账号与密码就可以拨号了。


GM220S后台地址及密码

后台地址：192.168.1.1

超级账号：CMCCAdmin

超级密码：aDm8H%MdA

概述


在软件系统中，某些类型由于自身的逻辑，它具有两个或多个维度的变化，那么如何应对这种“多维度的变化”？如何利用面向对象的技术来使得该类型能够轻松的沿着多个方向进行变化，而又不引入额外的复杂度？这就要使用
Bridge
模式。

意图


将抽象部分与实现部分分离，使它们都可以独立的变化。
[GOF 
《设计模式》
]

结构图




图
1 Bridge
模式结构图

生活中的例子


桥接模式将抽象部分与它的实现分离，使它们能够独立地变化。一个普通的开关控制的电灯、电风扇等等，都是桥接的例子。开关的目的是将设备打开或关闭。实际的开关可以是简单的双刀拉链开关，也可以是调光开关。



图
2 
使用电子开关例子的桥接对象图

桥接模式解说


在创建型模式里面，我曾经提到过抽象与实现，抽象不应该依赖于具体实现细节，实现细节应该依赖于抽象。看下面这幅图：



图
3  
抽象不应该依赖于实现细节

在这种情况下，如果抽象
B
稳定，而实现细节
b
变化，这时用创建型模式来解决没有问题。但是如果抽象
B
也不稳定，也是变化的，该如何解决？这就要用到
Bridge
模式了。

我们仍然用日志记录工具这个例子来说明
Bridge
模式。现在我们要开发一个通用的日志记录工具，它支持数据库记录
DatabaseLog
和文本文件记录
FileLog
两种方式，同时它既可以运行在
.NET
平台，也可以运行在
Java
平台上。

根据我们的设计经验，应该把不同的日志记录方式分别作为单独的对象来对待，并为日志记录类抽象出一个基类
Log
出来，各种不同的日志记录方式都继承于该基类：



图
4 Log
类结构图

实现代码如下：

public
 abstract
 class
 Log


{

    public
 abstract
 void
 Write(string
 log);

}

public
 class
 DatabaseLog
 : Log


{

    public
 override
 void
 Write(string
 log)

    {

        //......Log Database


    }

}

public
 class
 TextFileLog
 : Log


{

    public
 override
 void
 Write(string
 log)

    {

       //......Log Text File


    }

}

另外考虑到不同平台的日志记录，对于操作数据库、写入文本文件所调用的方式可能是不一样的，为此对于不同的日志记录方式，我们需要提供各种不同平台上的实现，对上面的类做进一步的设计得到了下面的结构图：



图
5 

实现代码如下：

public
 class
 NDatabaseLog
 : DatabaseLog


{

    public
 override
 void
 Write(string
 log)

    {

        //......(.NET

平台)Log Database

    }

}

public
 class
 JDatabaseLog
 : DatabaseLog


{

    public
 override
 void
 Write(string
 log)

    {

        //......(Java

平台)Log Database

    }

}

public
 class
 NTextFileLog
 : TextFileLog


{

    public
 override
 void
 Write(string
 log)

    {

        //......(.NET

平台)Log Text File

    }

}

public
 class
 JTextFileLog
 : TextFileLog


{

    public
 override
 void
 Write(string
 log)

    {

        //......(Java

平台)Log TextFile

    }

}

现在的这种设计方案本身是没有任何错误的，假如现在我们要引入一种新的
xml
文件的记录方式，则上面的类结构图会变成：



图
6

如图中蓝色的部分所示，我们新增加了一个继承于
Log
基类的子类，而没有修改其它的子类，这样也符合了开放
-
封闭原则。如果我们引入一种新的平台，比如说我们现在开发的日志记录工具还需要支持
Borland
平台，此时该类结构又变成了：



图
7

同样我们没有修改任何的东西，只是增加了两个继承于
DatabaseLog
和
TextFileLog
的子类，这也符合了开放
-
封闭原则。

但是我们说这样的设计是脆弱的，仔细分析就可以发现，它还是存在很多问题，首先它在遵循开放
-
封闭原则的同时，违背了类的单一职责原则，即一个类只有一个引起它变化的原因，而这里引起
Log
类
变化的原因却有两个，即日志记录方式的变化和日志记录平台的变化；其次是重复代码会很多，不同的日志记录方式在不同的平台上也会有一部分的代码是相同的；
再次是类的结构过于复杂，继承关系太多，难于维护，最后最致命的一点是扩展性太差。上面我们分析的变化只是沿着某一个方向，如果变化沿着日志记录方式和不
同的运行平台两个方向变化，我们会看到这个类的结构会迅速的变庞大。

现在该是
Bridge
模式粉墨登场的时候了，我们需要解耦这两个方向的变化，把它们之间的强耦合关系改成弱联系。我们把日志记录方式和不同平台上的实现分别当作两个独立的部分来对待，对于日志记录方式，类结构图仍然是：



图
8

现在我们引入另外一个抽象类
ImpLog
，它是日志记录在不同平台的实现的基类，结构图如下：



图
9

实现代码如下：

public
 abstract
 class
 ImpLog


{

    public
 abstract
 void
 Execute(string
 msg);

}

public
 class
 NImpLog
 : ImpLog


{

    public
 override
 void
 Execute(string
 msg)

    {

        //...... .NET

平台

    }

}

public
 class
 JImpLog
 : ImpLog


{

    public
 override
 void
 Execute(string
 msg)

    {

        //...... Java

平台

    }

}

这时对于日志记录方式和不同的运行平台这两个类都可以独立的变化了，我们要做的工作就是把这两部分之间连接起来。那如何连接呢？在这里，
Bridge
使用了对象组合的方式，类结构图如下：






图
 10

实现代码如下：


public
 abstract
 class
 Log


{

    protected
 ImpLog
 implementor;

 

    public
 ImpLog
 Implementor

    {

        set
 { implementor = value
; }    

    }

    public
 virtual
 void
 Write(string
 log)

    {

        implementor.Execute(log);

    }

}

public
 class
 DatabaseLog
 : Log


{

    public
 override
 void
 Write(string
 log)

    {

        implementor.Execute(log);

    }

}

public
 class
 TextFileLog
 : Log


{

    public
 override
 void
 Write(string
 log)

    {

        implementor.Execute(log);

    }

}

可以看到，通过对象组合的方式，
Bridge
模式把两个角色之间的继承关系改为了耦合的关系，从而使这两者可以从容自若的各自独立的变化，这也是
Bridge
模式的本意。再来看一下客户端如何去使用：

class
 App


{

    public
 static
 void
 Main(string
[] args)

    {

        //.NET

平台下的Database Log

        Log
 dblog = new
 DatabaseLog
();

        dblog.Implementor = new
 NImpLog
();

        dblog.Write();

        

        //Java

平台下的Text File Log

        Log
 txtlog = new
 TextFileLog
();

        txtlog.Implementor = new
 JImpLog
();

        txtlog.Write();

    }

}

可能有人会担心说，这样不就又增加了客户程序与具体日志记录方式之间的耦合性了吗？其实这样的担心是没有必要的，因为这种耦合性是由于对象的创建所带来的，完全可以用创建型模式去解决，就不是这里我们所讨论的内容了。

最后我们再来考虑一个问题，为什么
Bridge
模式要使用对象组合的方式而不是用继承呢？如果采用继承的方式，则
Log
类，
ImpLog
类都为接口，类结构图如下：



图
11

实现代码如下：

public
 class
 NDatabaseLog
 : DatabaseLog
, IImpLog


{ 

    //......


}

public
 class
 JDatabaseLog
 : DatabaseLog
, IImpLog


{ 

    //......


}

public
 class
 NTextFileLog
 : TextFileLog
, IImpLog


{ 

    //......


}

public
 class
 JTextFileLog
 : TextFileLog
, IImpLog


{ 

    //......


}

如上图中蓝色的部分所示，它们既具有日志记录方式的特性，也具有接口
IimpLog
的特性，它已经违背了面向对象设计原则中类的单一职责原则，一个类应当仅有一个引起它变化的原因。所以采用
Bridge
模式往往是比采用多继承更好的方案。说到这里，大家应该对
Bridge
模式有一些认识了吧？如果在开发中遇到有两个方向上纵横交错的变化时，应该能够想到使用
Bridge
模式，当然了，有时候虽然有两个方向上的变化，但是在某一个方向上的变化并不是很剧烈的时候，并不一定要使用
Bridge
模式。

效果及实现要点


1
．
Bridge
模式使用“对象间的组合关系”解耦了抽象和实现之间固有的绑定关系，使得抽象和实现可以沿着各自的维度来变化。

2
．所谓抽象和实现沿着各自维度的变化，即“子类化”它们，得到各个子类之后，便可以任意它们，从而获得不同平台上的不同型号。

3
．
Bridge
模式有时候类似于多继承方案，但是多继承方案往往违背了类的单一职责原则（即一个类只有一个变化的原因），复用性比较差。
Bridge
模式是比多继承方案更好的解决方法。

4
．
Bridge
模式的应用一般在“两个非常强的变化维度”，有时候即使有两个变化的维度，但是某个方向的变化维度并不剧烈——换言之两个变化不会导致纵横交错的结果，并不一定要使用
Bridge
模式。

适用性


在以下的情况下应当使用桥梁模式：

1
．如果一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性，避免在两个层次之间建立静态的联系。

2
．设计要求实现化角色的任何改变不应当影响客户端，或者说实现化角色的改变对客户端是完全透明的。

3
．一个构件有多于一个的抽象化角色和实现化角色，系统需要它们之间进行动态耦合。

4
．虽然在系统中使用继承是没有问题的，但是由于抽象化角色和具体化角色需要独立变化，设计要求需要独立管理这两者。

总结


Bridge
模式是一个非常有用的模式，也非常复杂，它很好的符合了开放
-
封闭原则和优先使用对象，而不是继承这两个面向对象原则。

参考资料


阎宏，《
Java
与模式》，电子工业出版社

James W. Cooper
，《
C#
设计模式》，电子工业出版社

Alan Shalloway James R. Trott
，《
Design Patterns Explained
》，中国电力出版社

MSDN WebCast 
《
C#
面向对象设计模式纵横谈
(8)
：
Bridge
桥接模式
(
结构型模式
)
》