1. Question:
A colleague received a new development task and needed to change the spring framework to springboot, but he encountered a problem that could not be solved for a long time.
The original project had a class like this:
public class MyTest{
private String name;
public String getName(){
return name;
}
public void setName(String name){
if(name!=null&&name.length <= 0){
this.name="defName";
}
}
}
This is a relatively conventional class with get and set methods. A little special is that this set method has certain logic processing.
In the previous project, this class was matched with a spring xml configuration file. This class was instantiated in the configuration file. The configuration file is roughly as follows:
<bean id="myTest" class="com.test.MyTest">
<property name="name">
<value>${name}
</property>
</bean>
Then set a specific value for name in the properties file.
Then his plan to change spring to springboot is to remove the configuration in xml and assign value to the name attribute directly by annotation.
The problem is that if you directly add the @value annotation to the name attribute, the logic processing in the original set method will be lost. If the logic processing in the set method is retained, the required value cannot be successfully obtained from the properties file.
2. Change of thinking
Then, he approached me to discuss this issue, and I actually don't know how the two are compatible.
However, after thinking and analysis, I feel that in this matter, it is not necessary to ensure the compatibility of the above two.
Here, the purpose of our set is just to give the name a correct value that we want to see. The important thing is not the set, but the get, because the content obtained by the get is what we will use later.
So obviously we can change our thinking, it does not mean that the logic must be in the set method, and it can be written in get.
Although the location of the logic implementation has changed, the content obtained in the end is the same, and the due functions are also realized.
3. Impressions
The software development process is a design process. Although there are some rules to follow in the design, the details are not static.
In many cases, it is impossible to walk in a straight line, and it is possible to detour a bit, and perhaps the time to reach the destination can be faster than the straight line.
The purpose of software design is not the software design itself, but to use software to solve practical problems. If you are blindly entangled with the code itself, rather than the actual problem to be solved, you may easily fall into a dead end and seriously reduce the efficiency of work.