I have a younger brother to learn to do the back-end Java development in a small Internet company, recently their company to a new technical director, the technical director of the technical details of great importance, after the company launched a lot of "policy", such as It defines a number of development norms, log specification, and even asked us to unify the use of a particular IDE.
But these are not the point of my brother and me to learn Tucao, and I Tucao he really is, he can not understand, the new technical director actually ban all development within the company use Lombok. But not any given very clear, people can reason convincing.
So he came to chat with me and asked me in the end this requirement is reasonable. About this, I think the starting point of the technical director is good, but the practice is somewhat extreme.
The reason why the starting point is good, because the use of Lombok does bring a lot of problems, but basically I personally do not actively use at work.
The reason why the use of the initiative say it is because some of my colleagues still use the code, so I was forced to install the plug-in Lombok.
Since this topic to talk about, simply talk about some of my views.
Lombok What are the benefits?
Java Lombok is a very useful tool to help developers eliminate Java code is lengthy, especially for simple Java objects (POJO). It does this by a comment.
For a better understanding if we Lombok, you can skip this section, direct look back, if not very familiar with, you can simply find out.
Lombok want to use in the project, it requires three steps:
A, IDE plug-in installation Lombok
Lombok currently supports a variety of IDE, including mainstream Eclips, Intellji IDEA, Myeclipse are all supported.
Installation in IDEA as follows:
Second, the introduction of dependencies
Lombok supports the use of multiple tools to build import dependence, is currently the main support maven, gardle, ant etc support.
As used maven introduced as follows:
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>1.18.12</version>
<scope>provided</scope>
</dependency>
复制代码Third, the code using annotations
Lombok way to streamline the code is mainly achieved through annotations, which are commonly used @ Data, @ Getter / @ Setter, @ Builder, @ NonNull and so on.
Such as the use @Data annotations, you can simply define a Java Bean:
import lombok.Data;
@Data
public class Menu {
private String shopId;
private String skuMenuId;
private String skuName;
}
复制代码Use @Data annotation on the class, the equivalent of using both @ ToString, @ EqualsAndHashCode, @ Getter, @ Setter and @RequiredArgsConstrutor these annotations, POJO class is useful for.
Examples help to automatically Menu class defined toString, Getter, Setter like.
By the above example, we may find that we are easy to use @Data comment greatly reduces the amount of code, the code is very simple. This is also a lot of developers are keen to use the main reason of Lombok.
In addition, on Lombok, and different people have different views, because many people have used Lombok, for his merits are more understanding, so let's talk about what issues the focus of the use of Lombok will bring.
Lombok any harm?
Strong X teammate
Because use of claim Lombok developer corresponding plug must be installed in the IDE.
If the plug is not installed, then use the IDE to open a project based on Lombok, then you will be prompted to find methods of error. Resulting in project compilation fails.
That is, if there is a team who uses Lombok, then other people must also install IDE plug-ins. Otherwise there is no way collaborative development.
More importantly, if we define a jar package used in Lombok, then all applications require all rely on this jar package must install the plug-in, which is highly invasive.
Code readability, debug low
Use the code in Lombok, can indeed help reduce a lot of code, because Lombok will help to automatically generate a lot of code.
But the code is to be generated only at compile time, so in the development process, in fact, a lot of code is actually missing.
Use a lot of Lombok in the code, has led to the readability of the code will be much lower, but also bring some problems to code debugging.
For example, we want to know a property getter methods of a class are referenced what kind of thing, not so simple.
Pit
Because Lombok make code development very easy, which makes the part of developers to its excessive dependence.
Lombok in use process, if the underlying principle for all kinds of annotations do not understand the words, it is easy to produce unexpected results.
To take a simple example, we know that when we use @Data a class definition, will automatically help us generate equals () method.
But if only a @Data, without using @EqualsAndHashCode (callSuper = true), then by default is @EqualsAndHashCode (callSuper = false), this time generated equals () method compares only the subclass of property, will not be considered , regardless of the parent class property access is open from the parent class inherits attributes.
This may get unexpected results.
Affect the upgrade
Because the code for Lombok has a strong invasive, it may bring a bigger issue that affects us upgrade the JDK.
Today, according to the frequency of the JDK upgrade every six months will launch a new version, but Lombok as a third-party tool, and is maintained by the open source team, his speed of iteration is not guaranteed.
So, if we need to upgrade to a new version of the JDK time, if one of the properties that are not supported in Lombok in words will be affected.
There may bring a problem, that is, Lombok own upgrade will be limited.
Because an application may depend on a number of jar package, and each jar package may have to rely on different versions of Lombok, which led to the application needs to be done in arbitration version, and we know, jar package versions arbitration is not so easy, and the probability of the occurrence of the problem is also high.
Destruction encapsulation
More than a few questions, I think there are ways to be avoided. But some people use exclusion there is another important reason Lombok, that is, he will destroy the encapsulation.
As we all know, Java's three major features include encapsulation, inheritance and polymorphism.
If we use Lombok directly from your code, then he will automatically help us generate getter, setter methods, which means that all the parameters are in a class automatically provides the setting and reading methods.
As a simple example, we define a shopping cart categories:
@Data
public class ShoppingCart {
//商品数目
private int itemsCount;
//总价格
private double totalPrice;
//商品明细
private List items = new ArrayList<>();
}
//例子来源于《极客时间-设计模式之美》
复制代码We know that there is a relationship before the number of shopping carts, product details and the total price of the three, if you need to modify the words are to be modified together.
However, we used @Data notes in Lombok, and for itemsCount totalPrice these two properties. Although we define them as private type, but provides a public getter, setter methods.
External change the values of these two properties by optionally setter method. We can call arbitrary setter methods to re-set itemsCount, totalPrice value of the property, which can lead to inconsistency with items whose value property.
And object-oriented package is defined: by the access control, hide internal data, external interface to access only a limited class provided by modifying internal data. Therefore, the exposure setter method should not be exposed to a clear violation of the object-oriented characteristics of the package.
Good practice should not provide getter / setter, but only to provide a method addItem public, while taking modify itemsCount, totalPrice items as well as three properties.
to sum up
This paper summarizes the advantages and disadvantages of commonly used Java development tools in Lombok.
The advantage of using annotations to help generate code automatically, greatly reducing the amount of code, the code is very simple.
But that does not mean the use of Lombok without any problems, the use of Lombok in the process, there may be unfriendly to his teammates, unfriendly code, debugging unfriendly, hostile upgrades and other issues.
Most importantly, the use of Lombok also lead to problems encapsulation of destruction.
Although Lombok there are a lot of convenience, but also brought some problems.
But in the end build is not recommended for use in the daily development, I actually keep a neutral attitude, we do not recommend over-reliance does not ask you do not have to complete.
As long as everyone in the use of the process, or do not want to evaluate before the introduction of Lombok in the code, while at the thought of his merits, taking into account the problems he can bring to the code, then the purpose of this paper is attained!
References:
time.geekbang.org/column/arti…