"SSH Advanced path" Step by step refactoring container implementation Spring Framework-starting with a simple container (eight)

Directory

"SSH Advanced path" Step by step refactoring container implementation Spring Framework-starting with a simple container (eight)

"SSH Advanced path" Step by step refactoring container to implement spring framework--two schemes to solve the "intrusive" management of containers for components--active lookup and control inversion (ix) (not updated)
"SSH Advanced path" Step by step refactoring container implementation Spring Framework-configuration file + Reflection implementation IOC container (10)(not updated)
"SSH Advanced path" Step by step refactoring container implementation Spring Framework-completely encapsulated for a simple and flexible spring Framework (11)(not updated)

Recently has been dealing with containers, and even the front of the blog, we also introduced the spring of the IOC principles and source code, but look back, duang~ duang~, or deep, not easy to understand, not enough in layman's. For these reasons, starting with this blog, we start with a simple container, step-up refactoring, and finally implement a basic spring framework, in order to help us understand the principles and source of Spring's IOC more deeply.

Container

I believe that we are not unfamiliar with the container, it is a very common life items, containers used to pack and load items of storage (such as boxes, cans, altars, etc.), but in the programming of what container? Let's look at the encyclopedia's explanation first:

--------------------------------------------------------------------------------------------------------------- ------------------------------------------

Containers can manage the life cycle of objects, dependencies between objects and objects, and you can use a configuration file (usually XML) that defines the name of the object, how it is produced (Prototype or singleton), Which object must be set to be a property of an object after the start of the container, all objects can be directly used, without writing any line of program code to produce objects, or to establish a dependency between objects and objects.

--------------------------------------------------------------------------------------------------------------- ------------------------------------------

See the above explanation, the first feeling is what thing? In plain parlance, a container is a module that is designed to manage objects. It is responsible for creating objects, managing dependencies on objects, managing the life cycle of objects, and so on, such as a module called a container.

Objects that run in containers are also known as components, and they must follow the specifications defined by the container.

Common Implementation

After we understand the container, let's start with a simple example. Check the code First:

Service Layer:

Public interface Service {public void Servicemethod ();}

Import Com.tgb.container.dao.dao;import Com.tgb.container.dao.impl.dao4mysqlimpl;import Com.tgb.container.service.service;public class Serviceimpl implements service {//Instantiate DAO implementation Private DAO DAO = new Dao4mysqlimpl ();  @Overridepublic void Servicemethod () {//Invoke DAO Implementation method Dao.daomethod ();}}

DAO Layer:

Public interface Dao {public void Daomethod ();}

Import Com.tgb.container.dao.dao;public class Dao4mysqlimpl implements DAO {public void Daomethod () {System.out.println ("Dao4mysqlimpl.daomethod ()");}}

Import Com.tgb.container.dao.dao;public class Dao4oracleimpl implements DAO {public void Daomethod () { System.out.println ("Dao4oracleimpl.daomethod ()");}}

Client:

Import Com.tgb.container.service.service;import Com.tgb.container.service.impl.serviceimpl;public class Client { public static void Main (string[] args) {//Instantiate service implementation Service service = new Serviceimpl ();// Call the service Implementation method Service.servicemethod ();}}

The result of this code operation, we can see at a glance, as follows:

dao4mysqlimpl.daomethod ()

The UML class diagram is as follows:

From what we can find, Serviceimpl not only relies on the DAO layer interface, but also relies on the DAO layer implementation, obviously violates the object-oriented basic design principle, relies on the reversal principle: the abstraction should not rely on the detail, the detail should depend on with the abstraction, plainly, is for the interface programming, does not implement the programming.

with Containers

Below we use the container to remove the dependent implementation relationship.

Container class:

Import Java.util.hashmap;import Java.util.map;import Com.tgb.container.dao.dao;import Com.tgb.container.dao.impl.dao4mysqlimpl;import Com.tgb.container.service.service;import Com.tgb.container.service.impl.serviceimpl;public class Container {//define a MAP structure object private static map<string, Object> components;private Container () {}/** * Initialize container */public static synchronized void init () {if (components = = NULL) {components = new hashmap<string, object> ();//write a read config file class, according to the read configuration file, reflect the corresponding class//reflection class after the dependency management, to the corresponding attribute to inject the corresponding class// When the client creates a new class, the container creates the class to pay the new class DAO Dao4mysql = Dao4mysqlimpl (); Components.put ("Dao4mysql", dao4mysql); Service service = new Serviceimpl ();  Components.put ("service", Service);}} /** * Find Component *  * @param ID * @return */public static Object getcomponent (String ID) {return components.get (ID);}}

To Modify the Serviceimpl class:

Import Com.tgb.container.container;import Com.tgb.container.dao.dao;import com.tgb.container.service.Service; public class Serviceimpl implements Service {//from the container to find the object of the response private DAO DAO = (dao) container.getcomponent ("Dao4mysql"); 
    @Overridepublic void Servicemethod () {Dao.daomethod ();}}

Client:

Import Com.tgb.container.container;import Com.tgb.container.service.service;public class Client {public static void Main (string[] args) {//container initialization, this can be done with filter, only one container.init () is initialized in the entire project;//lookup Interface Service service = (service) from the container Container.getcomponent ("service");//The method that invokes the service implementation Service.servicemethod ();}}

The UML class diagram at this point is as follows:

comparing two classes of graphs, we can find that the container brings us advantages, but also brings the disadvantage.

Advantages:

At this point the service layer is no longer dependent on the DAO layer implementation, and this dependency on the implementation is given to the container.

Disadvantages:

However, we find that Serviceimpl relies on the container container class, so that components can not be separated from the container independent existence, it is obvious that this is an "intrusive" management.

How to make a component independent of the container, see the blog "SSH Advanced Path" step-by-step refactoring container to implement the spring framework--the solution to the "intrusive" management of the container to the component two scenarios-activelookup and Control inversion (ix).

Source Download

"SSH Advanced path" Step by step refactoring container implementation Spring Framework-starting with a simple container (eight)