一、工厂模式       

 工厂模式提供了一种将对象的实例化过程封装在工厂类中的方式。通过使用工厂模式，可以将对象的创建与使用代码分离，提供一种统一的接口来创建不同类型的对象。定义一个创建对象的接口让其子类自己决定实例化哪一个工厂类，工厂模式使其创建过程延迟到子类进行。

工厂模式：
抽象产品（Abstract Product）：定义了产品的共同接口或抽象类。它可以是具体产品类的父类或接口，规定了产品对象的共同方法。
具体产品（Concrete Product）：实现了抽象产品接口，定义了具体产品的特定行为和属性。
抽象工厂（Abstract Factory）：声明了创建产品的抽象方法，可以是接口或抽象类。它可以有多个方法用于创建不同类型的产品。
具体工厂（Concrete Factory）：实现了抽象工厂接口，负责实际创建具体产品的对象。

实现创建一个 INoodles接口和实现 INoodles 接口的实体类。下一步是定义工厂类 INoodlesFactory。

public class NoodleFactory {
    /**
     * 规范下面条类型
     * */
    public static final int NOODLE_YOUPO = 1;
    public static final int NOODLE_REGAN = 2;
    public static final int NOODLE_LANZHOULA = 3;


    /**
     *创建面条
     **/
    public static  INoodles getNoodle(int type){
        if (type == 1){
            return new YouPoMianNoodleImp();
        }else if(type ==2){
            return new ReGanMianNoodleImp();
        }else if(type ==3 ){
            return new LanZhouLaMianImp();
        }
        return null;
    }


}

 

总结

工厂模式通过将对象的创建与使用分离，提供了更好的灵活性和可维护性。选择合适的工厂模式可以根据具体的需求和场景来决定。

二、代理模式 

什么是代理模式？

代理模式给某一个对象提供一个代理对象，并由代理对象控制对原对象的引用。通俗的来讲代理模式就是我们生活中常见的中介。     举个例子来说明：假如说我现在想买一辆二手车，虽然我可以自己去找车源，做质量检测等一系列的车辆过户流程，但是这确实太浪费我得时间和精力了。我只是想买一辆车而已为什么我还要额外做这么多事呢？于是我就通过中介自己喜欢的车，然后付钱就可以了。

为什么要用代理模式？

1.中介隔离作用：    

 在某些情况下，一个客户类不想或者不能直接引用一个委托对象，而代理类对象可以在客户类和委托对象之间起到中介的作用，其特征是代理类和委托类实现相同的接口。

2.开闭原则，增加功能： 代理类除了是客户类和委托类的中介之外，我们还可以通过给代理类增加额外的功能来扩展委托类的功能，这样做我们只需要修改代理类而不需要再修改委托类，符合代码设计的开闭原则。

有哪几种代理模式？ 我们有多种不同的方式来实现代理。如果按照代理创建的时期来进行分类的话 可以分为两种：

静态代理:         静态代理是由程序员创建或特定工具自动生成源代码，在对其编译。          在程序员运行之前，代理类.class文件就已经被创建了。

动态代理和静态代理是面向对象编程中的两种代理模式，它们的主要区别在于代理对象的创建方式以及使用场景。

静态代理

• 定义：静态代理是指在程序编译时就已经确定了代理类的实现。开发人员需要手动编写代理类，并将目标对象的功能进行封装。

• 优点：

  • 代理类可以针对某一个接口实现具体的业务逻辑。
  • 在编译时就能检查到错误。

• 缺点：

  • 每个需要代理的类都需要创建一个代理类，增加了代码量和维护成本。
  • 不适应于需要灵活修改代理逻辑的场合。

*      动态代理:
*              动态代理是在程序运行时通过反射机制动态创建的。
*              动态代理分为:
*                  基于接口的动态代理（jdk自带）
*                  基于子类的动态代理（第三方）

动态代理

• 定义：动态代理是在运行时根据指定的接口生成代理对象，不需要提前创建代理类。它通常使用 Java 的反射机制或其他框架（如 AOP）来实现。

• 优点：

  • 可以为多个类生成代理，不需要手动创建大量的代理类。
  • 灵活性高，可以在运行时决定代理的行为。

• 缺点：

  • 运行时生成可能会引入性能开销。
  • 难以进行编译时检查。

1.基于接口的动态代理（jdk自带）

原理：

JDK 自带的动态代理只能代理实现了接口的类。通过 java.lang.reflect.Proxy 类和 InvocationHandler 接口来实现。

2.基于子类的动态代理（第三方）

原理：

CGLIB（Code Generation Library）是一个强大的、高性能的代码生成库，它通过继承来实现代理。与 JDK 基于接口的动态代理不同，CGLIB 可以直接对类进行代理，只要所代理的类没有被声明为 final。

代码结构和说明

1. 被代理对象：通过IAccountService toProxyService指定了一个接口，该接口的实现会被代理。

2. 事务工具类：TransactionUtil transactionUtil用于处理事务的开始、提交和回滚。

3. 创建代理的createProxy方法：这个方法使用Java反射API创建一个代理对象，并在调用实际服务方法前后处理事务。

总结

• 基于接口的动态代理（JDK 自带）：

  • 只支持接口。
  • 使用简单，适合轻量级的场景。

• 基于子类的动态代理（CGLIB）：

  • 可以代理普通类（不必实现接口）。
  • 需要引入第三方库，适合复杂的业务逻辑。

在实际开发中，可以根据需求选择适合的动态代理方式。对于接口较多的场景，建议使用 JDK 自带的动态代理；而需要直接代理类时，则可以使用 CGLIB。

案例

public class ProxyBeanFactory {


    //1.被代理对象
    IAccountService toProxyService;

    public void setToProxyService(IAccountService toProxyService) {
        this.toProxyService = toProxyService;
    }

    //装配事务工具类
    TransactionUtil transactionUtil;

    public void setTransactionUtil(TransactionUtil transactionUtil) {
        this.transactionUtil = transactionUtil;
    }

    //2.创建代理
    public IAccountService createProxy(){
       IAccountService proxy = (IAccountService) Proxy.newProxyInstance(toProxyService.getClass().getClassLoader(), toProxyService.getClass().getInterfaces(), new InvocationHandler() {
            @Override
            public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
                Object o = null;
                try {
                    transactionUtil.beginTx();
                    o = method.invoke(toProxyService,args);
                    transactionUtil.commitTx();
                } catch (Exception e) {
                    e.printStackTrace();
                    transactionUtil.rollbackTx();
                } finally {
                    transactionUtil.closeTx();
                }
                return o;
            }
        });
       return proxy;
    }
}

 <!-- 事务工具类 -->
    <bean id="transactionUtil" class="com.xn.util.TransactionUtil">
        <property name="connectionUtil" ref="connectionUtil"/>
    </bean>

该bean负责管理事务，确保在数据库操作中能够正确处理事务的开始、提交和回滚。


    <!-- 注入dao -->
    <bean id="mapperImp" class="com.xn.dao.AccountMapperImp">
        <property name="queryRunner" ref="queryRunner"/>
        <property name="connectionUtil" ref="connectionUtil"/>
    </bean>

AccountMapperImp类负责与数据库交互，确保queryRunner和connectionUtil的正确配置以执行数据库操作。


    <!-- 注入被代理service -->
    <bean id="service" class="com.xn.service.AccountServiceImp">
        <property name="mapper" ref="mapperImp"/>
    </bean>

    <!-- 注入代理service -->
    <bean id="proxyService" class="com.xn.service.AccountServiceImp" factory-bean="factory" factory-method="createProxy"/>


    <bean id="factory" class="com.xn.factory.ProxyBeanFactory">
        <property name="transactionUtil" ref="transactionUtil"/>
        <property name="toProxyService" ref="service"/>
    </bean>


通过ProxyBeanFactory创建的proxyService用于在调用服务时添加额外的功能（如事务管理）。确保代理逻辑的实现能够正确处理服务调用。
    <!-- 注入controller -->
    <bean id="controller" class="com.xn.controller.AccountControllerImp">
        <property name="service" ref="proxyService"/>
    </bean>

AccountControllerImp类负责处理用户请求，并将请求委托给proxyService进行业务处理。

JAVA六大设计原则 

Java的六大设计原则（SOLID原则）是面向对象设计的重要指导方针，这些原则帮助开发者编写可维护、可扩展和易于理解的代码。具体包括：

1. 单一责任原则（Single Responsibility Principle）：

   • 一个类应该只有一个原因引起变化，即一个类只应该负责一项功能。这样可以提高模块化程度，降低类之间的耦合度。

2. 开放-关闭原则（Open/Closed Principle）：

   • 软件实体（类、模块、函数等）应该对扩展开放，对修改关闭。也就是说，在不修改现有代码的情况下，可以增加新功能，通过扩展现有的类或接口来实现。

3. 里氏替换原则（Liskov Substitution Principle）：

   • 子类对象应该能够替换父类对象，并且程序的行为不会发生变化。即实现继承时，子类应能无缝替换父类，保持程序的正确性。

4. 接口隔离原则（Interface Segregation Principle）：

   • 不应该强迫一个类依赖于它不需要的接口。许多特定的接口比一个通用接口更好，即应尽量使用多个小接口，避免接口的臃肿。

5. 依赖倒置原则（Dependency Inversion Principle）：

   • 高层模块不应依赖于低层模块，二者都应依赖于抽象（接口或抽象类）；而且抽象不应依赖于细节，细节应依赖于抽象。这样可以减少模块之间的耦合度。

6. 最少知识原则（Law of Demeter）（有时也包括在SOLID原则中，但不严格归入）：

   • 一个对象应该对其他对象有尽可能少的了解。也就是说，一个对象应该只与直接的朋友（协作对象）交互，而不与其他对象进行复杂的交互。

这些原则的作用

• 提高代码的可读性和可维护性：遵循这些原则，代码结构更加清晰易懂，维护的时候可以减少对其他模块的影响。
• 降低耦合度，提高内聚性：这些原则鼓励模块之间的松散耦合，增强了模块的独立性。
• 促进代码复用：良好的设计使得代码更容易在不同的项目中复用。
• 增强测试性：代码更容易被单元测试，提高了单元测试的可行性。

JAVA23种设计模式

在软件工程当中，设计原则和设计模式是不同的．

设计原则

设计原则是为了更好的设计软件的高层指导方针．　

它不提供具体的实现方式也不会绑定任何一种编程语言．　　

最常用的原则是SOLID（SRP, OCP, LSP, ISP, DIP）原则

设计模式

设计模式对关于面向对象问题的具体解决方案．

比如说,如果你想创建一个类而且它在任何时刻只会有一个对象，那么你就应该使用单例类模式．

设计模式是经过大量检测的安全的做法．

“饿汉式”和“懒汉式”是单例模式的两种实现方式。它们在实例化对象的时机和方式上存在明显的区别。下面分别介绍这两种方式。

1. 饿汉式

特点：

• 实例在类加载时就被创建，所以线程安全。
• 不支持延迟加载，因为实例一旦创建就存在，占用资源。
• 实现简单，代码少。

/**
 * 饿汉式
 * */
public class Student {
    //3.创建static修饰的成员变量
    private static Student stu = new Student();

    //1.设计私有构造方法
    private Student(){
        super();
    }

    //2.提供共有的方法
    public static synchronized Student getInstance(){
        return stu;
    }

}


//true

2. 懒汉式

特点：

• 实例在第一次调用时才被创建，支持延迟加载。
• 需要考虑线程安全问题。
• 代码稍微复杂，因为需要进行同步处理。

实现：

有多种方式实现懒汉式，以下是其中两种常见的实现。

 线程安全的懒汉式（使用 synchronized）

/**
 * 懒汉式
 * */
public class Student {
    //3.创建static修饰的成员变量
    private static Student stu;

    //1.设计私有构造方法
    private Student(){
        super();
    }

    //2.提供共有的方法
    public static synchronized Student getInstance(){
        if(stu == null){
             stu = new Student();
        }
        return stu;
    }

}

//true

总结

• 饿汉式：

  • 实例在类加载时创建，线程安全。
  • 一旦加载即占用资源，不支持延迟加载。

• 懒汉式：

  • 实例在第一次调用时创建，支持延迟加载。
  • 需要处理线程安全问题，代码相对复杂。

选择使用哪种方式一般依据具体的业务需求、性能考虑和资源管理来定。在一些早期的项目中，懒汉式较受欢迎，而在现代的多线程环境中，饿汉式因其简单和线程安全的特性也常被使用。

3、普通