Explain DI in an obese story
Introduction
This article is the 12th day article of Java Advent Calendar 2018.
It's been about half a year since I came into contact with Java DI. I was in a hurry to teach new members of the team, so I will summarize it in an article for my review.
Here is a sample project. https://github.com/segurvita/FatnessChecker
Target of this article
For those who understand classes and constructors, but don't know DI well.
I'll try to explain it with only classes and constructors so that I can understand it without knowing Bean or ʻInterface`.
I don't understand the meaning of "DI means dependency injection"
―― “DI is an abbreviation for Dependency Injection” ← Hmm Hmm ―― “Dependency Injection means Dependency Injection” ←? ?? ?? -"Strictly speaking, it is the injection of dependency objects" ←? ??
The purpose of this article is to understand the meaning of this ** Dependency Injection **.
DI means not using new in the class!
Don't be afraid to misunderstand, ** DI means don't use new in a class **. (I understand that it is not an accurate expression, but this article will be explained with an emphasis on clarity.)
Non-DI pattern
public class Hoge{
//Field (member variable)
Fuga piyo;
//Constructor
public Hoge() {
//I'm using new in my class.
this.piyo = new Fuga();
}
}
DI pattern
public class Hoge{
//Field (member variable)
Fuga piyo;
//Constructor
public Hoge(Fuga mogera) {
//Do not use new. I'm injecting from the outside.
this.piyo = mogera;
}
}
- Injecting with the constructor is just an example. If you inject from the outside, you can use a setter.
However, I do not understand the merit with this alone. From here, I will explain in a story format.
Episode 1: I went to an obesity judgment company
A story that starts suddenly
: man: Am I fat? That's it! Let's ask an obesity judgment company for inspection!
After several hours
: person_frowning: Welcome to the obesity assessment company. What kind of business do you have today?
: man: I want to judge the degree of obesity.
: person_frowning: You are a customer who judges the degree of obesity. Is it okay to ask for height and weight?
: man: Well, I'm 170 cm tall and weigh 70 kg.
: person_frowning: I'm clever. Please wait a moment. We will calculate BMI with our latest robot.
: robot: Calculation Shimasu ・ ・ ・ 70kg ÷ 1.70m de, BMI Ha ** 41.18 ** Death!
: person_frowning: If your BMI is 41.18 ... it's over 40, so it's ** 4 degrees obese **.
: man: Yeah! Such!
After several hours
: man: It's absolutely strange that I'm obese. Isn't that robot a bug?
What is BMI
BMI (body mass index) is calculated by weight (kg) ÷ height (m) ÷ height (m).
Is the calculation of: robot: wrong?
What is obesity judgment?
In Japan, people with a BMI of 25 or above are considered ** obese **. There are four stages of obesity, from 1 to 4 degrees.
Image quote: OMRON / vol.103 Revised diagnostic criteria for obesity for the first time in 11 years
Your role
The characters who appeared in the first episode are as follows.
-: Man: is a person who wants to know his or her obesity level. Since it is a user, we will call it ʻUser. -: Person_frowning: is the reception desk of the obesity judgment company. Do not calculate BMI yourself, but ask: robot: to do it. The degree of obesity can be determined based on the BMI value. Let's call it FatnessChecker. -: Robot: is a robot that calculates BMI. There is still a bug in the prototype. Let's call it BmiRobot`.
Problem of the case of the first episode
: robot: BmiRobot made a mistake in calculating BMI. Apparently there is a bug.
Based on this wrong calculation result,: person_frowning: FatnessChecker made an obesity judgment, so the judgment result was also wrong.
In other words, the problem is that: person_frowning: FatnessChecker relied on an unreliable robot called: robot: BmiRobot.
Episode 2: Appearance of BMI Sennin
: man: It's absolutely strange that I'm obese. Isn't that robot a bug?
: older_man: Is that person having trouble with BMI calculation?
: man: Who are you!
: older_man: I'm a BMI hermit. Please tell me the story if you like.
: man: Yeah, it's actually a secret ...
A few days later
: information_desk_person: Welcome to the obesity assessment company. (Omitted) May I ask you about your height and weight?
: man: Height is 170 cm and weight is 70 kg. However, I will ask this person to calculate the BMI, not the robot the other day.
: older_man: Hohoho, in this case 70kg ÷ 1.70m ÷ 1.70m, BMI is ** 24.22 **.
: information_desk_person: I'm clever. If your BMI is 24.22 ... it's more than 18.5 and less than 25, so it's ** normal weight **.
: man: I did it! I'm not obese at the last minute!
Your role
The characters who appeared in the second episode are as follows.
-: Man: is a person who wants to know his or her obesity level. Since it is a user, we will call it ʻUser. -: Older_man: is a master at calculating BMI. I've trained a lot, so I'll never make a mistake in the calculation. Let's call it BmiMaster. -: Information_desk_person: is a person who uses: older_man: to determine the degree of obesity. It is the same person as: person_frowning :, but for the sake of explanation, we will distinguish it and call it FatnessCheckerDi`.
DI solution
: man: ʻUserasked: information_desk_person:FatnessCheckerDi to determine the degree of obesity under the condition that: older_man: BmiMaster` should calculate the BMI.
As a result, the judgment result of: information_desk_person: FatnessCheckerDi depends on the reliable person:: older_man: BmiMaster.
This is ** DI ** (Dependency Injection)! In other words
: man: ʻUserinjects: older_man:BmiMaster into: information_desk_person: FatnessCheckerDi`!
Benefits of DI
The advantage of DI is that ** you can unit test the part under development even if the dependent part is not completed **.
In this case, there was a bug in: robot: BmiRobot, so if it didn't work, it would be okay if we did enough testing and reduced the bug in: robot: BmiRobot. ?? I think there is also an opinion. (I thought so at first.)
However, it will take some time to ** test enough **.
: person_frowning: FatnessChecker depends on: robot: BmiRobot, so you can't test: person_frowning: FatnessChecker until: robot: BmiRobot is complete. This will increase development time.
On the other hand,: information_desk_person: FatnessCheckerDi allows the dependent parts (: older_man: BmiMaster) to be injected from the outside (: man: ʻUser). By doing this, even if the dependent part (: older_man: BmiMaster) is not completed, if you inject a mock (test-only haribote) of the dependent part (: older_man: BmiMaster),: information_desk_person: Unit testing of FatnessCheckerDi` is possible.
Disadvantages of DI
The disadvantage is that ** the learning cost is high **.
In the case of team development, if DI is adopted in the project under development, all members will need to learn DI. Education costs can be non-negligible for teams with a lot of member turnover.
Sample code
I think that it is difficult to convey with just sentences, so I will explain it with Java code.
Here is a sample project. https://github.com/segurvita/FatnessChecker
: robot: When calculated with BmiRobot (before DI introduction)
First,: man: ʻUser` looks like this.
User.java
/**
*People who want to know the degree of obesity
*/
public class User {
/**
*Ask an obesity judgment company to make a judgment without a BMI master.
*/
public void runWithoutBmiMaster() {
//Start a conversation with a person from an obesity judgment company.
FatnessChecker fatnessChecker = new FatnessChecker();
//Tell them your height and weight and ask them to determine your obesity.
String result = fatnessChecker.check(170.0, 70.0);
//The judgment result of the degree of obesity is displayed.
System.out.println("Obesity judgment result (without BMI master):" + result);
}
}
You are requesting work at fatnessChecker.check.
Then: person_frowning: FatnessChecker looks like this:
FatnessChecker.java
/**
*Obesity judgment company (using BMI robot)
*/
public class FatnessChecker {
/**
*Determine BMI
* @param height height[cm]
* @param weight weight[kg]
* @return obesity
*/
public String check(double height, double weight) {
//Secure one of the latest BMI robots in the company.
BmiRobot bmiRobot = new BmiRobot();
//Ask the BMI robot to calculate BMI.
double bmi = bmiRobot.calc(height, weight);
//Determine the degree of obesity from the BMI calculation results.
if (bmi < 18.5) {
return "Underweight";
} else if (bmi < 25.0) {
return "Normal weight";
} else if (bmi < 30.0) {
return "Once obese";
} else if (bmi < 35.0) {
return "Twice obese";
} else if (bmi < 40.0) {
return "3rd degree obesity";
} else {
return "4th degree obesity";
}
}
}
In the check method,new BmiRobot ()is used to reserve one: robot: BmiRobot.
After that, BMI calculation is requested by BmiRobot.calc (height, weight), and the degree of obesity is judged based on the calculation result.
If there is a bug in: robot: BmiRobot, the judgment result will be wrong. : robot: Depends on BmiRobot.
That: robot: BmiRobot is implemented, for example:
BmiRobot.java
/**
*BMI robot (with bugs)
*/
public class BmiRobot {
/**
*Calculate BMI
* @param height height[cm]
* @param weight weight[kg]
* @return BMI
*/
public double calc(double height, double weight) {
//body weight[kg]÷ Height[m]
return weight * 100 / height;
}
}
The formula is Weight [kg] ÷ Height [m], which is incorrect.
If you run the program in this state, the result will be
Execution result
Obesity judgment result (without BMI master): 4th degree obesity
It will be.
: older_man: When calculated with BmiMaster (after DI introduction)
First,: man: ʻUser` looks like this.
User.java
/**
*People who want to know the degree of obesity
*/
public class User {
/**
*With a BMI master, ask an obesity judgment company to make a judgment.
*/
public void runWithBmiMaster() {
//Secure one BMI master.
BmiMaster bmiCalculator = new BmiMaster();
//Ask a person from an obesity assessment company to make the BMI calculation a BMI master.
FatnessCheckerDi fatnessCheckerDi = new FatnessCheckerDi(bmiCalculator);
//Tell them your height and weight and ask them to determine your obesity.
String result = fatnessCheckerDi.check(170.0, 70.0);
//The judgment result of the degree of obesity is displayed.
System.out.println("Obesity judgment result (with BMI master):" + result);
}
}
The big difference from the previous one is that: man: ʻUser uses new BmiMaster () and reserves one: older_man: BmiMaster. This is passed to: information_desk_person: FatnessCheckerDi with new FatnessCheckerDi (bmiCalculator) `.
Then: information_desk_person: FatnessCheckerDi looks like this:
FatnessCheckerDi.java
/**
*Obesity judgment company (using BMI master)
*/
public class FatnessCheckerDi {
/**
*BMI master
*/
final private BmiMaster bmiMaster;
/**
*constructor
* @param bmiCalculator BMI master named by the user
*/
public FatnessCheckerDi(BmiMaster bmiMaster) {
//We welcome the BMI master nominated by the user.
this.bmiMaster = bmiMaster;
}
/**
*Determine BMI
* @param height height[cm]
* @param weight weight[kg]
* @return obesity
*/
public String check(double height, double weight) {
//Ask the BMI master nominated by the user to calculate the BMI.
double bmi = this.bmiMaster.calc(height, weight);
//Determine the degree of obesity from the BMI calculation results.
if (bmi < 18.5) {
return "Underweight";
} else if (bmi < 25.0) {
return "Normal weight";
} else if (bmi < 30.0) {
return "Once obese";
} else if (bmi < 35.0) {
return "Twice obese";
} else if (bmi < 40.0) {
return "3rd degree obesity";
} else {
return "4th degree obesity";
}
}
}
The big difference from the previous one is the appearance of the constructor.
Earlier, in the check method, we reserved one: robot: BmiRobot, but this time we receive: older_man: BmiMaster as an argument of the constructor and use it as a field (member variable). ) Is assigned.
After that, we request BMI calculation with this.bmiMaster.calc (height, weight) and judge the degree of obesity based on the calculation result.
Now it depends on: older_man: BmiMaster.
That: older_man: BmiMaster is implemented, for example:
BmiMaster.java
/**
*BMI Master (Master)
*/
public class BmiMaster {
/**
*Calculate BMI
* @param height height[cm]
* @param weight weight[kg]
* @return BMI
*/
public double calc(double height, double weight) {
//body weight[kg] ÷ (height[m])^2
return weight * 10000 / (height * height);
}
}
The formula is weight [kg] ÷ (height [m]) ^ 2. This is the correct formula.
If you run the program in this state, the result will be
Execution result
Obesity judgment result (with BMI master): Normal weight
It will be.
Bonus: Where on earth should I new?
In this story,: man: ʻUser prepares: older_man: BmiMaster (new) and injects it into: information_desk_person: FatnessCheckerDi`.
So if: man: ʻUseritself was also designed with a DI pattern, who would prepare: older_man:BmiMaster`?
: man: ʻWill there be another class outside of User`? What if even that class was designed with a DI pattern?
That's where the ** DI container ** comes in. Undertakes the processing of new at once.
In the case of Java Spring, BeanFactory corresponds to this.
at the end
What did you think. I tried to explain DI in a story style.
When I first touched DI half a year ago, I was buried in unknown terms such as ʻAutowired and BeanFactory`, and it became "DI difficult ...". (At that time, there was no distinction between DI and DI container.)
However, when I coded it for half a year and looked back, I thought, "Isn't it possible to explain DI without knowing that it's actually Bean? ", So I wrote this article for myself half a year ago. I tried it.
I hope it will be helpful to you.
Reference site
I referred to the following site.