设计模式六种常用模式

一、原则

运用实例operation测试接口隔离的方式

调试过程和解决问题办法：

1、Maven的配置和安装。完成eclipse Maven jar插件的下载。遇到Mavenjar下载失败和版本不对应出现uml画图错误。

2、删除根目录重新安装。查看windows -> Preferences -> maven 的settings.xml文件中.m2的位置，然后将.m2/repository/org/apache/maven/plugins目录下的文件夹全部删除，选中maven项目，右键àmavenàupdate让maven重新下载依赖包。

3、配置低版本的jdk 。将jdk1.8，直接改在电脑path里面的路径，tomcat是8.5，maven项目在eclipse新建项目的时候，第一次会下载很多jar包，都是在线下的，需要自己去那个网址里面去下对应的jar包，把他们添加到对应的目录下面去，将pom.xml进行配置下载链接

    <id>Central</id>

    <url>http://repo1.maven.org/maven2</url>

    <mirrorOf>central</mirrorOf>

</mirror>

4、pom.xml的配置。建立Maven工程，打开pom.xml,添加如下代码

    <groupId>junit</groupId>

    <artifactId>junit</artifactId>

    <version>4.13.2</version>

</dependency>

5、UML安装与配置。将

net.java.amateras.xstream_1.3.4.jar

net.java.amateras.umleditor_1.3.4.jar、

net.java.amateras.umleditor.java_1.3.4.jar

三个jar包复制到dropins目录下面，然后重启eclipse就能够建类图。

6、绘制UML类图。新建Class Diagrarn newfile.cld，添加4个Class类和一个interface，利用Dependencyhe和Realization进行连接和继承，点击java export生成对应的包，建立完成。

接口隔离原则是客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。第一个uml图是类A依赖接口I中的方法1、方法2、方法3，类B是对类A依赖的实现。类C依赖接口I中的方法1、方法4、方法5，类D是对类C依赖的实现。对于类B和类D来说，虽然他们都存在着用不到的方法，但由于实现了接口I，所以也必须要实现这些用不到的方法。第二个uml图是接口过于臃肿，只要接口中出现的方法，不管对依赖于它的类有没有用处，实现类中都必须去实现这些方法，如果将这个设计修改为符合接口隔离原则，就必须对接口I进行拆分。此图将原有的接口I拆分为三个接口。最后得知运用接口隔离原则一定要适度接口设计的过大或过小都不好。设计接口的时候，多花些时间去思考和筹划，才能准确地实践这一原则。

二、依赖倒置原则、里氏替换原则

利用依赖倒置原则验证信息的显示和里氏替换原则验证数字输出

调试过程和解决问题办法：

1、A类直接依赖B类，假如要将A类改为依赖C类，则必须通过修改A类的代码来达成。这种场景下，A类一般是高层模块，负责复杂的业务逻辑；B类和C类是低层模块，负责基本的原子操作；修改A类，会给程序带来不必要的风险。

2、将A类修改为依赖接口I，B类和C类各自实现接口I，A类通过接口I间接与B类或者C类发生联系，则会大大降低修改A类的几率。

3、有一功能P1，由A类完成。现需要将功能P1进行扩展，扩展后的功能为P，其中P由原有功能P1与新功能P2组成。新功能P由A类的子B类来完成，则子B类在完成新功能P2的同时，有可能会导致原有功能P1发生故障。

4、当使用继承时，遵循里氏替换原则。B类继承A类时，除添加新的方法完成新增功能P2外，尽量不要重写父类A的方法，也尽量不要重载父类A的方法。

用依赖倒置原则的方法是接口传递和构造方法传递，在实际运用时注意低层都要有抽象类或者接口，变量的声明类型也都要是抽象类或者接口，使用继承时就遵守里氏替换原则。里氏替换原则的子类可以扩展父类的功能，但是不能改变父类原有的功能，应该多使用父类与子类都继承一个更通俗的基类，将原有的继承关系去掉，采用依赖、聚合、组合等关系代替。

三、迪米特法则

运用迪米特法则实现学校管理的实现

调试过程和解决问题办法：

1、类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。

2、尽量降低类与类之间的耦合。

迪米特法则是用来解决耦合率高的缘故，利用迪米特法则可以降低耦合率，从而提高代码的复用率。迪米特法则避免与非直接的类通信，但是要通信，必然会通过一个“中介”来发生联系，过度的使用迪米特法则会产生大量的中介和传递类，导致系统的复杂度大。所以在采用迪米特法则时要反复权衡，既做到结构清晰，又要高内聚低耦合。

四、开闭原则

运用开闭原则对扩展开放，对修改关闭

调试过程和解决问题办法：

1、在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会给旧代码中引入错误，也可能会使我们不得不对整个功能进行重构，并且需要原有代码经过重新测试。

2、当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。

开闭原则就是对扩展开放，对修改关闭，结果研究和总结，我认为开闭原则应该是用抽象构建框架，用实现扩展细节，灵活性比较强，适应性广，只要抽象类合理，可以保持软件及代码的稳定性，也容易进行扩展，只需要一个派生的实现类就可以扩展。对于其它几个原则来说，开闭原则是总纲，对扩展开放，对修改关闭。

五、单例模式

运用单例模式实现七个类

调试过程和解决问题办法：

1、懒汉式单例的实现没有考虑线程安全问题，它是线程不安全的，并发环境下很可能出现多个Singleton实例，可以使用双重检查和静态内部类进行，可以保证线程安全，又避免了同步带来的性能影响。
2、饿汉式在类创建的同时就已经创建好一个静态的对象供系统使用，以后不再改变，所以天生是线程安全的。

单例模式为一个面向对象的应用程序提供了对象惟一的访问点，不管它实现何种功能，整个应用程序都会同享一个实例对象。懒汉式和饿汉式的区别饿汉就是类一旦加载，就把单例初始化完成，保证getInstance的时候，单例是已经存在的了，而懒汉比较懒，只有当调getInstance的时候，才回去初始化这个单例。线程的安全，线程在同时运行代码时，如果每次运行结果和单线程运行的结果是一样的，而且其他的变量的值也和预期的是一样的，就是线程安全的。

六、工厂模式

实现简单工厂模式

调试过程和解决问题办法：

1、建立水果工厂项目，通过工厂模式的特性，建立工厂、水果、水果种类的类，通过构造函数进行调用，使其共有，客户端进行调用展现水果成长的实现。

2、工厂类的私有化（private）或者共同化（static），在其工厂类或者mian前面加入对应的static可保证问题的解决。

通过使用简单的工厂模式,分析出工厂模式的适用场景，1、工厂类负责创建的对象比较少：由于创建的对象较少，不会造成工厂方法中的业务逻辑太过复杂。2、客户端只知道传入工厂类的参数，对于如何创建对象不关心：客户端既不需要关心创建细节，甚至连类名都不需要记住，只需要知道类型所对应的参数。其优点是客户端可以免除直接创建产品的对象责任。通过引入配置文件，可以在不修改任何客户端代码的情况下更换和增加新的具体产品类，在一定程度上提高了系统的灵活性。其缺点也很明显，由于工厂类集中了所有产品的逻辑，如果工厂类不能正常运行，整个系统就会收到影响。简单工厂模式运用了静态工厂方法，造成工厂角色无法形成基于继承的等级结构。