1.桥接模式：这种模式下，虚拟机和物理机连的是同一个网络，虚拟机和物理机是并列关系，地位是相当的。比如，你家有路由器，那么你的电脑和你的手机同时连接这个路由器提供的Wi-Fi，那么它们的关系就是这种模式。
2.NAT模式：这种模式下，物理机会充当一个“路由器”的角色，虚拟机要想上网，必须经过物理机，那物理机如果不能上网，虚拟机也就不能上网了。之所以说这种模式兼容性最好，是因为物理机的网络环境变化时，虚拟机的网络并不会有影响，比如，上班时你把物理机连接在公司的网络环境中，下班后又把物理机连接在你家的路由器上。你公司的网段有可能和你家的网段是不同的。桥接模式下，虚拟机和物理机一样，都要自动获取IP才可以上网，而做实验的时候，是需要把虚拟机设置为静态IP的，这样就导致虚拟机网络不稳定。而设置为NAT模式，虚拟机的网络并不需要依赖你公司的网络环境或者你家的网络环境。
3.仅主机模式：这种模式下，相当于拿一根网线直连了物理机和虚拟机。
--------------------- 
作者：eaglezsx 
来源：CSDN 
原文：https://blog.csdn.net/zsx157326/article/details/77806625?utm_source=copy 
版权声明：本文为博主原创文章，转载请附上博文链接！

 

工厂模式其实在java中用到的还是比较常见的，因为工厂模式个人认为十分契合java面向对象编程的原理，具体来说，

工厂模式是什么 ：

工厂通过对外暴露出接口，然后你只需要通过工厂来拿到你所需要的对象。这样做的好处有两点，

1.你不需要去关注对象具体怎么实现的，你只要直接得到就行；

2. 降低耦合度。 在你的代码中不必直接与用到的对象发生关系，便于后期的维护。假如对象需要作出改变，那与你现在的业务代码也不必直接冲突，便于降低耦合，易于代码的分工开发与后期的维护。

举个例子说明下：

假如我想喝饮料了，咱们最直接的想法是，我去商店买饮料，而不是我去买原料然后制作饮料。这里的商店就是指的是工厂，而我想喝饮料 就是指的是我在coding时需要的新的对象。

 

 

工厂模式分类：

其实只有三种：   工厂方法模式，简单工厂模式 ，抽象工厂模式 

第二种基于第一种基础上简化，第三种基于第一种基础上复杂化。

 

1.工厂方法模式：

 

普通工厂模式 就是这样的，有专门的可乐饮料商店，有专门的雪碧饮料商店；

我想要哪个饮料就去对应的商店买。

先上代码 ： 

代码主要分为4块 ，产品抽象类（饮料类），产品具体类（可乐饮料类 雪碧饮料类），工厂抽象类（饮料工厂） ，工厂具体类 （可乐饮料工厂 ，雪碧饮料工厂）

产品抽象类（饮料类）：

/**
 * FileName: Drink
 * Author:   Administrator
 * Date:     2019/5/30 0030 下午 4:52
 * Description: 所有饮料的父类
 
 */
package moshi;

public class Drink {
    public void say(){
        System.out.println("所有的饮料和女人一样都是水做的");
    }
}


产品具体类（可乐饮料类 雪碧饮料类）:

/**
 * Copyright (C), 2015-2019, XXX有限公司
 * FileName: spriteDrinke
 * Author:   Administrator
 * Date:     2019/5/30 0030 下午 5:01
 * Description: 雪碧饮料
  
 */
package moshi;

public class spriteDrinke extends Drink {
    @Override
    public void say() {
        System.out.println("我是雪碧 -- 喝进去满嘴放炮");
    }
}




/**
 * Copyright (C), 2015-2019, XXX有限公司
 * FileName: cokeDrinke
 * Author:   Administrator
 * Date:     2019/5/30 0030 下午 4:55
 * Description: 可乐饮料
 */
package moshi;

public class cokeDrinke extends Drink{
    @Override
    public void say() {
        System.out.println("我是可口可乐~~~~灰不溜的 还挺好喝");
    }
}

  工厂抽象类（饮料工厂） ：

package moshi;

/**
 *
 * 〈这是饮料商店的接口〉
 *
 * @author Administrator
 * @create 2019/5/30 0030
 * @since 1.0.0
 */

public interface inteFactory {
    Drink creatDrink();
}

工厂具体类 （可乐饮料工厂 ，雪碧饮料工厂）：

/**
 * Copyright (C), 2015-2019, XXX有限公司
 * FileName: sprintFactory
 * Author:   Administrator
 * Date:     2019/5/30 0030 下午 5:04
 * Description: 雪碧工厂
 
 */
package moshi;

public class sprintFactory implements  inteFactory {
    @Override
    public spriteDrinke creatDrink() {
        return new spriteDrinke();
    }
}


/**
 * Copyright (C), 2015-2019, XXX有限公司
 * FileName: cokeFactory
 * Author:   Administrator
 * Date:     2019/5/30 0030 下午 5:03
 * Description: 可口可乐工厂
 */
package moshi;

public class cokeFactory implements  inteFactory {
    @Override
    public cokeDrinke creatDrink() {
        return new cokeDrinke();
    }
}


测试类 ：

/**
 * Copyright (C), 2015-2019, XXX有限公司
 * FileName: mainTest
 * Author:   Administrator
 * Date:     2019/5/30 0030 下午 12:06
 */
package moshi;

public class mainTest {
 
public static void main(String[] args) {
   cokeFactory cf = new cokeFactory();
   sprintFactory sf = new sprintFactory();

   //  我想要一个 可乐
    Drink cd = cf.creatDrink();
    cd.say();
    //  我想要一个 雪碧
    Drink sp = sf.creatDrink();
    sp.say();
}
}


2.简单工厂模式:

/**
 * Copyright (C), 2015-2019, XXX有限公司
 * FileName: drinkSimpleFactory
 * Author:   Administrator
 * Date:     2019/5/30 0030 下午 6:15
 * Description: 简单工厂模式
 
 */
package moshi;

public class drinkSimpleFactory  {

    public  static cokeDrinke  createCokeDrink(){
        return new cokeDrinke();
    }
    public  static spriteDrinke  createspriteDrinke(){
        return new spriteDrinke();
    }
}

从demo里我们看到，或许这只是单纯的把new 对象这个功能简单的封装到了工厂类里，从代码两种没有看到啥特别的优点，但是 其实个人理解，工厂模式作为创建模式的一种，他更好的将我们的降低耦合，隐藏了创建过程的复杂度，我们专注的是做好我们的业务逻辑功能的实现，其他的我们可以不做的就尽量交给其他处理，而现实中实际接触到的，比较典型的用例就是 spring 的控制反转。

 3. 抽象工厂模式

抽象工厂模式不同于以上两者的地方就是在于，每个工厂不在单纯的生产某一个产品，生产的是一类产品组，比如可乐工厂生产的有罐装的可乐，还有瓶装的可乐。是所有可乐这个大类下的所有产品族。

----

后话，没有任何一种模式是完美无缺的，当他降低耦合的时候，可能代码就多了；

然后在项目中，框架中我们肯定碰到这种模式，比如数据库的配置，我们通过一个简单的json配置文件的简单修改，然后框架可以通过xml对应的映射，然后改变数据库的连接和相关属性；那么这就是一种 配置文件 + 反射机制+ 工厂模式 搞定的。

 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~·华丽的分割线~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 水平有限，不足之处 还望不吝指出 感激感激在感激！

里氏替换原则：在子类对象出现的地方用父类对象来替换，并不会改变程序的逻辑行为。

  这其实在纠正我们面向字面理解的一个错误，在coding的世界里，父类与子类的关系不是现实生活当中的父与子关系，不应出现基因变异，按照里氏替换原则的要求，父类与子类在父类已有定义的行为上表现应该完全一致，子类应该是父类功能上的补充。

  1. 首先最明显的一点：子类不与父类所注释或者所表达的功能是违反里氏替换原则原则的

  2. 子类的输入或者输出或者说抛出异常以及对异常处理的方式（抛出还是捕获）与父类不一致是违反里氏替换原则的

总结来说就是，子类在实现父类功能时，与父类功能上应该保持一致

 

这里记录一下观察者模式，偶尔会用到，也比较好理解。
观察者模式：定义了一种一对多的依赖关系，让多个观察者对象同时监听一个主题对象，在主题对象改变时会同时通知所有注册的观察者对象，使它们能够自动更新自己。
采用原书场景：办公室员工为观察者，所有人都约定（订阅）了前台小姐姐，如果老板回来就通知他们，他们收起小差继续工作。
你会怎么写代码，是就前台类，员工类吗？
原书UML如下：

这里对员工和通知者（前台，或者老板【走后门进来前台不知道】）进行了抽象，不然在员工类里会依赖具体的通知者类，通知者类里也会依赖具体的员工类，这样通知者类更换了，员工类也必须修改对象类型，就耦合了，不利于拓展和维护。
测试类如下：
package com.gcc.ObserverModel;
/**
 * 观察者模式：定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。
 * 在这个主题地下变化时，会通知所有观察着对象，使它们自动更新某个动作。
 * 
 * 本例解释：生成一个通知者，这个人可以是前台可以是老板等等。 new ReceptionNotify()
 * 			 生成希望接到通知的观察者，同时赋予姓名和希望得到哪个通知者.new ObserverA("张三",renotify)
 * 			 通知者添加他愿意通知的人.renotify.addObserver(oa)
 * 			 通知者设置通知的内容状态.renotify.setState("前台状态：老板回来了");
 * 			 通知者发送通知.renotify.notifyAction();
 */
public class TestObserver {

	public static void main(String[] args) {
		ReceptionNotify renotify = new ReceptionNotify();
		ObserverA oa = new ObserverA("张三",renotify);
		ObserverB ob = new ObserverB("李四",renotify);
		ObserverC oc = new ObserverC("王五",renotify);
		
		renotify.addObserver(oa);
		renotify.addObserver(ob);
		renotify.addObserver(oc);
		renotify.removeObserver(ob);//取消订阅通知
		
		renotify.setState("前台状态：老板回来了");
		renotify.notifyState();
		renotify.notifyAction();
		System.out.println();
		
		//----------------------------------------
		BossNotify bossNotify = new BossNotify();
		ObserverA oa2 = new ObserverA("张三",bossNotify);
		ObserverB ob2 = new ObserverB("李四",bossNotify);
		ObserverC oc2 = new ObserverC("王五",bossNotify);
		
		
		bossNotify.addObserver(oa2);
		bossNotify.addObserver(ob2);
		bossNotify.addObserver(oc2);
		
		bossNotify.setState("老板状态：本老板回来了");
		bossNotify.notifyState();
		bossNotify.notifyAction();
		
		
		
		
	}
	
}
员工（观察者）接口：
package com.gcc.ObserverModel;

public interface Observer {

	void update();
	
}
员工类：
package com.gcc.ObserverModel;

public class ObserverA implements Observer {

	String name;
	Notify notify;
	
	public ObserverA() {
		super();
	}

	public ObserverA(String name,Notify notify) {
		super();
		this.name = name;
		this.notify = notify;
	}

	public void askNotifyState(){
		this.notify.notifyState();
	}
	
	@Override
	public void update() {
		System.out.println(this.name+"关闭NBA直播，继续工作");
	}

}
package com.gcc.ObserverModel;

public class ObserverB implements Observer {

	String name;
	Notify notify;
	
	public ObserverB() {
		super();
	}

	public ObserverB(String name,Notify notify) {
		super();
		this.name = name;
		this.notify = notify;
	}


	@Override
	public void update() {
		System.out.println(this.name+"关闭股票行情，继续工作");
	}

}
package com.gcc.ObserverModel;

public class ObserverC implements Observer {

	String name;
	Notify notify;
	
	public ObserverC() {
		super();
	}

	public ObserverC(String name,Notify notify) {
		super();
		this.name = name;
		this.notify = notify;
	}

	@Override
	public void update() {
		System.out.println(this.name+"关闭新番动漫，继续工作");
	}

}
通知（主题）接口：
package com.gcc.ObserverModel;

public interface Notify {

	void addObserver(Observer observer);
	void removeObserver(Observer observer);
	void notifyAction();
	void notifyState();
	
}
通知类：
package com.gcc.ObserverModel;

import java.util.ArrayList;
import java.util.List;

public class ReceptionNotify implements Notify {

	private String state;
	
	public String getState() {
		return state;
	}
	public void setState(String state) {
		this.state = state;
	}

	
	List<Observer> list = new ArrayList<Observer>();
	
	@Override
	public void addObserver(Observer observer) {
		list.add(observer);
	}

	@Override
	public void removeObserver(Observer observer) {
		list.remove(observer);
	}

	@Override
	public void notifyAction() {
		for (Observer o : list) {
			o.update();
		}
	}

	@Override
	public void notifyState() {
		System.out.println(this.state);
	}

}
package com.gcc.ObserverModel;

import java.util.ArrayList;
import java.util.List;

public class BossNotify implements Notify {

	private String state;
	
	public String getState() {
		return state;
	}
	public void setState(String state) {
		this.state = state;
	}

	
	List<Observer> list = new ArrayList<Observer>();
	
	@Override
	public void addObserver(Observer observer) {
		list.add(observer);
	}

	@Override
	public void removeObserver(Observer observer) {
		list.remove(observer);
	}

	@Override
	public void notifyAction() {
		for (Observer o : list) {
			o.update();
		}
	}

	@Override
	public void notifyState() {
		System.out.println(this.state);
	}

}
运行结果如下：
前台状态：老板回来了
张三关闭NBA直播，继续工作
王五关闭新番动漫，继续工作
老板状态：本老板回来了
张三关闭NBA直播，继续工作
李四关闭股票行情，继续工作
王五关闭新番动漫，继续工作
简单来理解，观察者模式就是解除耦合，让耦合的双方都依赖于抽象（接口），而不依赖于具体，从而使得各自的变化不会影响另一方。
感谢观看，咧。