Spring随堂笔记

Spring

1、IoC控制反转

IoC特点不用new 就可以初始化类;

控制反转的英文名叫 Ioc(Inversion of Control) ,依赖注入英文名叫DI(Dependency Injection)

类之间的关系,不用代码控制,而是由Spring容器(也就是Spring的jar包)来控制。控制权由代码翻转到容器里,这叫控制反转。

表现形式:再初始化对象时,在代码里无须new 而是把类之间的关系写到配置文件里。

2、DI 依赖注入

在代码运行时,,如果我们要在一个类里面使用(也叫注入)另一个类,那么这种注入就是依赖配置文件的。

表现形式:同样是把类的关系写道配置文件里,在运行时会根据配置文件把类注入到另一个类里。

依赖注入常用知识点说明:在spring里,通常在配置文件文件中描述各类以及各类之间的包含关系,在使用的时候,先加载配置文件,Spring的内核会读取配置文件,随后动态的组装各类。

Spring读取配置文件的方式归纳:

类名:XmlBeanFactory 

例子:

Resource  resource = new ClassPathResource(“bean.xml”);

BeanFactory factory = new XmlBeanFactory(resource);

类名:ClassPathXmlApplicationContext

例子:

ApplicationContext factory = new ClassPathXmlApplicationContext(“conf/application.xml”);

类名:用文件系统类读取 FileSystemXmlApplicationContext

例子:

ApplicationContext factory = new FileSystemApplicationContext(“classpath:application.xml”);

单例多例,有状态无状态Bean:

我们知道,Spring的容器会在程序运行时,根据配置文件自动创建(或者实例化)具体的Java类(也叫Class,或叫Bean),在配置文件里,可以设置创建文件时是否用单例的方式,如果没有设置,则会自动默认的单利方式来创建。

如果不是单例,则可以用下面语法来修改,它们是等价的。

<bean id=”Jinzekeji” class=”cn.com.codinfun.entity” singleton=”false”>

或者<bean id=”Jinzekeji” class=”cn.com.codinfun.entity” scope=”protrotype”>

3、AOP面向切面编程

3.1简介:

AOP 是 Aspect Oriented Programming 的缩写,译为面向切向编程。用我们最常用的 OOP 来对比理解:

纵向关系 OOP,横向角度 AOP

设计一个日志打印模块。按 OOP 思想,我们会设计一个打印日志 LogUtils 类,然后在需要打印的地方引用即可。

public class ClassA {
    private void initView() {
        LogUtils.d(TAG, "onInitView");
    }
}

public class ClassB {
    private void onDataComplete(Bean bean) {
        LogUtils.d(TAG, bean.attribute);
    }
}

public class ClassC {
    private void onError() {
        LogUtils.e(TAG, "onError");
    }
}

看起来没有任何问题是吧?

但是这个类是横跨并嵌入众多模块里的,在各个模块里分散得很厉害,到处都能见到。从对象组织角度来讲,我们一般采用的分类方法都是使用类似生物学分类的方法,以「继承」关系为主线,我们称之为纵向,也就是 OOP。设计时只使用 OOP思想可能会带来两个问题:

  1. 对象设计的时候一般都是纵向思维,如果这个时候考虑这些不同类对象的共性,不仅会增加设计的难度和复杂性,还会造成类的接口过多而难以维护(共性越多,意味着接口契约越多)。

  2. 需要对现有的对象 动态增加 某种行为或责任时非常困难。

而AOP就可以很好地解决以上的问题,怎么做到的?除了这种纵向分类之外,我们从横向的角度去观察这些对象,无需再去到处调用 LogUtils 了,声明哪些地方需要打印日志,这个地方就是一个切面,AOP 会在适当的时机为你把打印语句插进切面。

// 只需要声明哪些方法需要打印 log,打印什么内容
public class ClassA {
    @Log(msg = "onInitView")
    private void initView() {
    }
}

public class ClassB {
    @Log(msg = "bean.attribute")
    private void onDataComplete(Bean bean) {
    }
}

public class ClassC {
    @Log(msg = "onError")
    private void onError() {
    }
}

OOP 与 AOP 的区别

  1. 面向目标不同:简单来说 OOP 是面向名词领域,AOP 面向动词领域。

  2. 思想结构不同:OOP 是纵向结构,AOP 是横向结构。

  3. 注重方面不同:OOP 注重业务逻辑单元的划分,AOP 偏重业务处理过程中的某个步骤或阶段。

OOP 与 AOP 的联系

两者之间是一个相互补充和完善的关系。

如果说 OOP 是把问题划分到单个模块的话,那么 AOP 就是把涉及到众多模块的某一类问题进行统一管理。AOP的目标是把这些功能集中起来,放到一个统一的地方来控制和管理。利用 AOP 思想,这样对业务逻辑的各个部分进行了隔离,从而降低业务逻辑各部分之间的耦合,提高程序的可重用性,提高开发效率。

3.2、应用场景

那AOP既然这么有用,除了上面提到的打印日志场景,还有没有其他用处呢?

当然有!

只要系统的业务模块都需要引用通用模块,就可以使用AOP。以下是一些常用的业务场景:

3.2.1 参数校验和判空

系统之间在进行接口调用时,往往是有入参传递的,入参是接口业务逻辑实现的先决条件,有时入参的缺失或错误会导致业务逻辑的异常,大量的异常捕获无疑增加了接口实现的复杂度,也让代码显得雍肿冗长,因此提前对入参进行验证是有必要的,可以提前处理入参数据的异常,并封装好异常转化成结果对象返回给调用方,也让业务逻辑解耦变得独立。

3.2.2 Android API23+的权限控制

避免到处都是申请权限和处理权限的代码

3.2.3 无痕埋点

3.2.4 安全控制

比如全局的登录状态流程控制。

3.2.5日志记录

3.2.6事件防抖

防止View被连续点击触发多次事件

3.2.7 性能统计

检测方法耗时其实已经有一些现成的工具,比如 trace view。痛点是这些工具使用起来都比较麻烦,效率低下,而且无法针对某一个块代码或者某个指定的sdk进行查看方法耗时。可以采用 AOP 思想对每个方法做一个切点,在执行之后打印方法耗时。

3.2.8 事务处理

声明方法,为特定方法加上事务,指定情况下(比如抛出异常)回滚事务

3.2.9 异常处理

替代防御性的 try-Catch。

3.2.10 缓存

缓存某方法的返回值,下次执行该方法时,直接从缓存里获取。

3.2.11 软件破解

使用 Hook 修改软件的验证类的判断逻辑。

3.2.12 热修复

AOP 可以让我们在执行一个方法的前插入另一个方法,运用这个思路,我们可以把有 bug 的方法替换成我们下发的新方法。

通过ORM专注业务

原文地址:https://www.cnblogs.com/mzdljgz/p/11184690.html