Spring容器注入与面向对象编程的思考-优快云博客

本文链接：https://blog.youkuaiyun.com/liuhongtaowxp1/article/details/123567165

在Spring中，容器注入对象的方法主要有两种，分别是构造函数注入方式与set方法注入方式，其中构造函数方法可以根据参数索引，类型和名称来适配。
例子如下：实体类 Student.java

public class Student {
private String message;

                public void setMessage(String message) {
                this.message = message;
                  }
                public Student(){
                System.out.println("Student对象实例化");
                  }
                public Student(String name){
                System.out.println("Student对象实例化 name="+name);
                  }
                public Student(int i,String name){
                System.out.println("Student对象实例化");
                System.out.println("i="+i+" name="+name);
                }
                public void printmessage(){
                System.out.println(message);
                  }

}

构造函数注入方式：

<bean name="stun" id="stu" class="com.java.demo.Student"></bean>

<bean name="stu1" class="com.java.demo.Student">


<constructor-arg index="0" value="10"></constructor-arg>
<constructor-arg index="1" value="10"></constructor-arg>
</bean>
<bean name="stu2" class="com.java.demo.Student">

<constructor-arg type="int" value="12"></constructor-arg>
<constructor-arg type="String" value="12"></constructor-arg>
</bean>
<bean name="stu3" class="com.java.demo.Student">


<constructor-arg name="i" value="13"></constructor-arg>
<constructor-arg name="name" value="13"></constructor-arg>
</bean>

通过set方法来注入：对message属性进行赋值即依靠属性方法来注入

<bean name="stu4" class="com.java.demo.Student">
        <property name="message" value="初始的信息"></property>
       </bean>
        相信上面的两种方式，不管是xml方式，还是java 文件的配置方式，作为开发的大家已经非常熟悉了。大家日复一日，年复一年的使用这种方法。但是很少有人对这种方式提出质疑，因为在MVC模式的开发中，大家都是这样去使用的。@controller,@service,@resposity配置controller,service,dao。业务逻辑全部堆积在service层，如果对于大型复杂系统来说，这无疑致命的。在service层的方法代码里，有着上万行的代码，各种if esle,各种工具类，各种方法调用方法。对于新增新的需求或者对原有业务逻辑的改造，动一个方法的逻辑，可能造成各种新的bug。

为什么会这样，大家有想过吗？归咎原因，是因为一行代码承担了太多的职责。为了满足一个职责，做的改动，影响了其他职责。就spring容器有解决方案吗？可能有人会提到设计模式，但是我觉得mvc开发模式+spring容器从本质上是面向过程的开发模式，从spring容器配置方式，构造函数的参数都是预先配置好的，我们根本无法在运行时，根据动态的参数去实例化对象，spring容器的方式约束了面向对象编程的方式。spring容器倡导使用spring容器实例化后的对象，而这些对象都是spring事先实例化的，我们无法使用类的构造函数去实例化对象，（如果自己实例化对象又和spring容器实例化的对象掺和在一起了）无法施展面向对象编程的威力。连spring容器的作者也承认spring容器继承了EJB容器的血统，本质上是面向过程的开发。而设计模式和面向过程的编程方法在一起，让人觉得莫名其妙，总感觉别扭。设计模式只有在面向对象编程基础上才能发挥威力。所以设计模式和mvc开发模式交织在一起，只能解决部分问题。现在流行的ddd领域驱动设计，是完全面向对象的，只有ddd+设计模式的思想才能解决复杂系统上述的问题。我们的逻辑不用写在service层里，而是分解到具体的对象（领域模型）里，每个对象，每个方法都有单一的职责。改某一个对象的方法，不会波及其他的逻辑。

反spring容器