一文让你知道Spring架构设计

阳光穿透心脏的1/2处 2023-09-25 22:33 57阅读 0赞

### 前言 ###

为什么需要Spring? 什么是Spring?

对于这样的问题，大部分人都是处于一种朦朦胧胧的状态，说的出来，但又不是完全说的出来，今天我们就以架构设计的角度尝试解开Spring的神秘面纱。

本篇文章以由浅入深的方式进行介绍，大家不必惊慌，我可以保证，只要你会编程就能看懂。

> 本篇文章基于Spring 5.2.8，阅读时长大概需要20分钟

### 案例 ###

我们先来看一个案例：有一个小伙，有一辆吉利车， 平常就开吉利车上班

![format_png][]

代码实现：

public class GeelyCar {
    
        public void run(){
            System.out.println("geely running");
        }
    }
    复制代码

public class Boy {
    		// 依赖GeelyCar
        private final GeelyCar geelyCar = new GeelyCar();
    
        public void drive(){
            geelyCar.run();
        }
    }
    复制代码

有一天，小伙赚钱了，又买了辆红旗，想开新车。

简单，把依赖换成`HongQiCar`

![format_png 1][]

代码实现：

public class HongQiCar {
    
        public void run(){
            System.out.println("hongqi running");
        }
    }
    复制代码

public class Boy {
        // 修改依赖为HongQiCar
        private final HongQiCar hongQiCar = new HongQiCar();
    
        public void drive(){
            hongQiCar.run();
        }
    }
    复制代码

新车开腻了，又想换回老车，这时候，就会出现一个问题：这个代码一直在改来改去

很显然，这个案例违背了我们的**依赖倒置原则(DIP)**:程序不应依赖于实现，而应依赖于抽象

#### 优化后 ####

现在我们对代码进行如下优化：

![format_png 2][]

`Boy`依赖于`Car`接口，而之前的`GeelyCar`与`HongQiCar`为`Car`接口实现

代码实现：

定义出Car接口

public interface Car {
    
        void run();
    }
    复制代码

将之前的`GeelyCar`与`HongQiCar`改为`Car`的实现类

public class GeelyCar implements Car {
    
        @Override
        public void run(){
            System.out.println("geely running");
        }
    }
    复制代码

> HongQiCar相同

Person此时依赖的为`Car`接口

public class Boy {
    		// 依赖于接口
        private final Car car;
    		
        public Person(Car car){
            this.car = car;
        }
    
        public void drive(){
            car.run();
        }
    }
    复制代码

此时小伙想换什么车开，就传入什么参数即可，代码不再发生变化。

#### 局限性 ####

以上案例改造后看起来确实没有什么毛病了，但还是存在一定的局限性，如果此时增加新的场景：

有一天小伙喝酒了没法开车，需要找个代驾。代驾并不关心他给哪个小伙开车，也不关心开的是什么车，小伙就突然成了个抽象，这时代码又要进行改动了，代驾依赖小伙的代码可能会长这个样子：

private final Boy boy = new YoungBoy(new HongQiCar());
    复制代码

随着系统的复杂度增加，这样的问题就会越来越多，越来越难以维护，那么我们应当如何解决这个问题呢？

#### 思考 ####

首先，我们可以肯定：使用**依赖倒置原则**是没有问题的，它在一定程度上解决了我们的问题。

我们觉得出问题的地方是在传入参数的过程：程序需要什么我们就传入什么，一但系统中出现多重依赖的类关系，这个传入的参数就会变得极其复杂。

或许我们可以把思路**反转**一下：我们有什么，程序就用什么！

当我们只实现`HongQiCar`和`YoungBoy`时，代驾就使用的是开着`HongQiCar`的`YoungBoy`！

当我们只实现`GeelyCar`和`OldBoy`时，代驾自然而然就改变成了开着`GeelyCar`的`OldBoy`！

而如何反转，就是Spring所解决的一大难题。

### Spring介绍 ###

Spring是一个一站式轻量级重量级的开发框架，目的是为了解决企业级应用开发的复杂性，它为开发Java应用程序提供全面的基础架构支持，让Java开发者不再需要关心类与类之间的依赖关系，可以专注的开发应用程序(crud)。

Spring为企业级开发提供给了丰富的功能，而这些功能的底层都依赖于它的两个核心特性:依赖注入(DI)和面向切面编程(AOP)。

#### Spring的核心概念 ####

IoC容器

IoC的全称为`Inversion of Control`，意为控制反转，IoC也被称为依赖性注入(DI)，这是一个通过依赖注入对象的过程：对象仅通过构造函数、工厂方法，或者在对象实例化在其上设置的属性来定义其依赖关系(即与它们组合的其他对象)，然后容器在创建bean时注入这些需要的依赖。这个过程从根本上说是Bean本身通过使用直接构建类或诸如服务定位模式的机制，来控制其依赖关系的实例化或位置的逆过程（因此被称为控制反转）。

> 依赖倒置原则是IoC的设计原理，依赖注入是IoC的实现方式。

容器

在Spring中，我们可以使用XML、Java注解或Java代码的方式来编写配置信息，而通过配置信息，获取有关实例化、配置和组装对象的说明，进行实例化、配置和组装应用对象的称为容器。

一般情况下，我们只需要添加几个注解，这样容器进行创建和初始化后，我们就可以得到一个可配置的，可执行的系统或应用程序。

![format_png 3][]

Bean

在Spring中，由Spring IOC容器进行实例化—>组装管理—>构成程序骨架的对象称为Bean。Bean就是应用程序中众多对象之一。

> 以上三点串起来就是：Spring内部是一个放置Bean的IoC容器，通过依赖注入的方式处理Bean之间的依赖关系。

AOP

面向切面编程(Aspect-oriented Programming)，是相对面向对象编程(OOP)的一种功能补充,OOP面向的主要对象是类，而AOP则是切面。在处理日志、安全管理、事务管理等方面有非常重要的作用。AOP是Spring框架重要的组件，虽然IOC容器没有依赖AOP，但是AOP提供了非常强大的功能，用来对IOC做补充。

AOP可以让我们在不修改原有代码的情况下，对我们的业务功能进行增强：将一段功能切入到我们指定的位置，如在方法的调用链之间打印日志。

#### Spring的优点 ####

1、Spring通过DI、AOP来简化企业级Java开发

2、Spring的低侵入式设计，让代码的污染极低

3、Spring的IoC容器降低了业务对象

[format_png]: https://img-blog.csdnimg.cn/img_convert/4fc9cde7f9027d8f745f7d24c66784fc.webp?x-oss-process=image/format,png
[format_png 1]: https://img-blog.csdnimg.cn/img_convert/421941a7794d54effd247df036e9cc00.webp?x-oss-process=image/format,png
[format_png 2]: https://img-blog.csdnimg.cn/img_convert/b0c9c2aa3c2fcd20f408aab3a1883bfa.webp?x-oss-process=image/format,png
[format_png 3]: https://img-blog.csdnimg.cn/img_convert/ca36e24e0b5e010e56585a1a935bfccd.webp?x-oss-process=image/format,png