Spring的设计模式----工厂模式及对象代理

最新推荐文章于 2024-08-12 19:14:37 发布

小白nn

最新推荐文章于 2024-08-12 19:14:37 发布

阅读量1k

点赞数 11

文章标签：设计模式 java 开发语言

本文链接：https://blog.csdn.net/m0_74002833/article/details/141001529

版权

一、工厂模式

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

工厂模式：
抽象产品（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。

代码结构和说明

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

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

创建代理的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负责管理事务，确保在数据库操作中能够正确处理事务的开始、提交和回滚。


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

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


    
    <bean id="service" class="com.xn.service.AccountServiceImp">
        <property name="mapper" ref="mapperImp"/>
    </bean>

    
    <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用于在调用服务时添加额外的功能（如事务管理）。确保代理逻辑的实现能够正确处理服务调用。
    
    <bean id="controller" class="com.xn.controller.AccountControllerImp">
        <property name="service" ref="proxyService"/>
    </bean>

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

JAVA六大设计原则

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

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

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

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

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

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

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

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

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

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

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

最少知识原则（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、普通

小白nn

关注

11
点赞
踩
28

收藏

觉得还不错? 一键收藏
0
评论
Spring的设计模式----工厂模式及对象代理

工厂模式通过将对象的创建与使用分离，提供了更好的灵活性和可维护性。选择合适的工厂模式可以根据具体的需求和场景来决定。二、代理模式什么是代理模式？代理模式给某一个对象提供一个代理对象，并由代理对象控制对原对象的引用。通俗的来讲代理模式就是我们生活中常见的中介。举个例子来说明：假如说我现在想买一辆二手车，虽然我可以自己去找车源，做质量检测等一系列的车辆过户流程，但是这确实太浪费我得时间和精力了。我只是想买一辆车而已为什么我还要额外做这么多事呢？于是我就通过中介自己喜欢的车，然后付钱就可以了。
复制链接

扫一扫