Spring Combat (4th edition) reading notes record

Let's look at an example of an old Java object Pojo:

Package com.habuma.spring;

public class helloworldbean{

Public String Sayhelllo () {

Return "Hello World";

}

}

DI

One of the important functions of spring is the dependency injection, where we can assemble the Pojo code above to help the application objects remain loosely coupled to each other.

The implication is that in real-world applications, there are two or more than two classes that need to work together to accomplish a particular function. Each object is responsible for managing its own

A reference to a mutually collaborative object (that is, the object it depends on), which can result in highly coupled and hard-to-test code.

Let's look at a tight coupling example:

Package com.springinaction.knight;

public class Damselrescuingknight implements knight{

Private Rescuedameselquest Quest;

Public Damselrescuingknight () {

This.quest=new rescuedamselquest ();//tight coupling with rescuedamselquest

}

public void Embarkonquest () {

Quest.embark ();

}

}

This tight coupling has two drawbacks, on the one hand damselrescuingknight and rescuedameselquest coupled, so limiting the knight's ability. On the other hand the coupled code

Difficult to test, difficult to reuse and understand.

Di can solve these two problems very well, and dependency injection will automatically hand over the dependent relationship to the target object, instead of getting the object to rely on itself. Let's take a look at the following example:

Package com.springinaction.knights;

public class Braveknight implements knight{

Private Quest Quest

The public braveknight (Quest Quest) {//quest was injected, Braveknight did not create an adventure task on its own, but instead injected it as a constructor parameter, which is constructor injection.

The task type here is quest, so that all the expedition mission to achieve an interface, braveknight can do rescuedamselquest, slaydragonquest and other arbitrary quest implementation.

This.quest=quest;

}

public void Embarkonquest () {

Quest.embark ();

}

}

The most common way to replace dependencies is to use a mock implementation when testing. The test code is not explained in detail.

Let's look at how to pass a specific expedition to the knight:

Package com.springination.knights;

Import Java.io.printStream;

public class Slaydragonquest implements quest{

Private PrintStream stream;

Public slaydragonquest (PrintStream stream) {

This.stream=stream;

}

public void Embark () {

Stream.println ("Embarking on quest to slay the dragon!");

}

}

Assembly

Creating the behavior of collaboration between app components is what we call assembly. Spring has many ways of assembling beans, and using XML is a common way of assembling.

Let's take a look at this configuration file Knights.xml, which assembles Braveknight, Slaydragonquest, and Printsstream together.

<?xml version= "1.0" encoding== ' UTF-8 "?>

<beans xmlns= "Http://www.springframework.org/schema/beans"

Xmlns= "Http://www-instance.w3.org/2001/XMLSchema-instance"

Xsi:schemalocation= "Http://www.springframework.org/schema/beans

Http://www.springframework.org/schema/beans/spring-beans.xsd ">

<bean id= "Knight" class= "Com.springinaction.knights.BraveKnight" >

<constructor-arg ref= "Quest"/>// inject Quest beans

</bean>

<bean id= "Quest" class= "Com.springinaction.knights.SlayDragonQuest" >

<constructor-arg value= "#{t (System). Out}"/>

</bean>

</bean>

Spring Combat (4th edition) reading notes record