2018-03-27 Spring Tour

recently has been caught in a misunderstanding, always find some online on the SSM crash and other video learning, and then blindly follow the ' copy ' code, then after the video hit the code, to achieve some functions, I feel that I have enough knowledge about some of the frameworks such as spring (in fact, I don't know what it is.) After a period of time, the work is not used to spring, until one day to use, suddenly found that even manually build a basic spring project environment will not ... Waking understand ~ ~ Follow the video hit the code really is someone else's @[email protected]. Therefore, bought <spring action> this book, began the systematic understanding Spring (@[email protected]). After reading the first chapter, summed up a few of the points of knowledge:

Spring is a layered javase/ee full-stack (one-stop) lightweight, open-source framework. One of the stops is to use the spring framework to build a Web application, the DAO layer Spring JDBC template,web layer springmvc,service layer spring IOC. Spring's fundamental mission: simplifying Java development. So how does spring simplify Java development?

Around this mission, Spring takes the following 4 key strategies to reduce the complexity of Java development:

　　1. Pojo-based lightweight and minimal intrusive programming

POJO (Plain ordinary Java object): Simple Java objects, actually is the ordinary JavaBeans.

Intrusive programming: The framework binds the application to the framework by forcing the application to inherit their classes or implement their interfaces, and tightly coupled.

Spring does not force you to implement the Spring specification interface or the class that inherits the spring specification, and in a spring-based application, its class has no traces that you use spring, even if you use spring annotations in the class, but it is still pojo, This allows the application objects to remain loosely coupled to each other. So how does spring do that? One way is to assemble them through Di (dependency injection).

2. Loose coupling via Dependency injection and interface-oriented

　　Dependency Injection (DI): An object's dependencies are set by the system's third-party components that coordinate objects, and objects do not have to create or manage their dependencies on their own.

Any meaningful application will have two or more classes that work together to accomplish specific business logic. In traditional practice, each object is responsible for managing references to objects that it works with (that is, the objects it relies on), which can lead to highly coupled and hard-to-test code. As follows:

 PackageChapter1;ImportINFs. Knight; Public classDamselrescuingknightImplementsKnight {//references to objects that are dependent on the Damselrescuingknight class    PrivateRescuedamselquest Quest; /*** Create dependent objects in constructors*/     Publicdamselrescuingknight () { This. Quest =NewRescuedamselquest ();//tight coupling with rescuedamselquest    }         Public voidembarkonquest () {//the knight can only perform rescuedamselquest expedition missions .Quest.embark (); }}

In this code, the Damselrescuingknight and rescuedamselquest are tightly coupled, greatly restricting the knight's ability to carry out the expedition (i.e., the ability to extend the knight, and if a knight is needed to rescue it, another class must be written), Even worse, unit testing is not possible.

Coupling has two sides, on the one hand, tightly coupled code is difficult to test, difficult to reuse, difficult to understand; On the other hand, certain coupling is necessary, and different classes must interact in the appropriate way.

As below, spring through DI, to achieve the purpose of loose coupling.

Figure 1.1 Dependency injection automatically gives the dependent relationship to the target object, rather than letting the object get its own dependency

　　

 PackageChapter1;ImportINFs. Knight;ImportINFs. Quest; Public classBraveknightImplementsKnight {//using the Quest interface    PrivateQuest Quest; /*** Inject quest by constructor * As long as the class object that implements the quest interface can be injected *@paramQuest*/     Publicbraveknight (Quest Quest) { This. Quest =Quest; }         Public voidembarkonquest () {//I don't know what kind of quest it is.Quest.embark (); }}

The most important point of the above code is that Braveknight does not have a coupling with a particular quest implementation, and for it only requires the expedition mission to implement the Quest interface, specifically which type of expedition is irrelevant. This is the greatest benefit of di-loose coupling.

One of the most common ways to replace dependencies is to use mock implementations when testing.

 PackageChapter1;Import StaticOrg.mockito.mockito.*;Importorg.junit.Test;ImportINFs. Quest; Public classbraveknighttest {@Test Public voidknightshouldembarkonquest () {//Create a Quest object using a mock (class)Quest mockquest = mock (Quest.class); //Inject QuestBraveknight Knight =Newbraveknight (mockquest);        Knight.embarkonquest (); //when calling the Embarkonquest () method, using verify requires the Mockito framework to verify that the embark () method of Quest's mock implementation calls only onceVerify (Mockquest, Times (1) . Embark (); }}

Now that the Braveknight class can accept any kind of quest expedition, if I now need this brave knight to destroy a dragon, then how will the specific quest task of destroying the dragon be passed on to it?

 PackageChapter1;ImportJava.io.PrintStream;ImportINFs. Quest; Public classDestorydragonquestImplementsQuest {PrivatePrintStream Stream;  Publicdestorydragonquest (PrintStream stream) { This. Stream =stream; }         Public voidEmbark () {stream.println ("To destroy the Dragon!" "); }}

　　

2018-03-27 Spring Tour