Introduction:

I have been working on Java for 4 years since I graduated in 2013. I finally had the time to sit down and write an article about Java writing. I asked myself if you are a Java programmer, can you really write Java? The author is a pragmatic programmer, so this article is not bullshit article, the contents of the article are dry goods, hope readers look, can have harvest.

This article core

Actually, didn’t want to write the title of the terror, only to find a lot of people did a few years after the Java, all think is a good Java programmer, can take place his wages of tens of thousands of, the purpose of writing this article is not mocking the Java counterparts, as well as I do just want readers to see this cheat, can like me, Be calm and strive to be a good programmer.

About the direction

Technical point

This article is not a boast article, it will not talk about a lot of deep architecture, on the contrary, it will explain a lot of basic problems and writing problems, if the reader thinks that the basic problems and writing problems are not a problem, please ignore this article, save time to do something meaningful.

The development tools

Replace the IDE

I don’t even want to explain what IDE to switch to, if you want to be a good Java programmer, please switch to Intellij idea. For the benefits of using IDEA, please search Google.

Don’t tell me shortcuts don’t work

bean

Beans are one of our most used models, and I’ll cover beans at length in the hope that the reader gets a good feel for it.

Domain package name

DTO

Data transmission we should use DTO objects as the transmission object, this is our agreement, because I have been doing mobile API design work for a long time, many people tell me that they think only when transmitting data to mobile phone (input or output), these objects become DTO objects. Please pay attention! Such understanding is wrong. As long as the objects are used for network transmission, we all think they can be regarded as DTO objects. For example, in the e-commerce platform, when users place an order, the data after placing an order will be sent to OMS or ERP system.

We agree to change the name of an object to XXDTO if it is a DTO object, such as OMSOrderInputDTO.

DTO transformation

scenario

Operations such as adding members, because for demonstration, I only consider the user’s some simple data, when the background administrator click add user, only need to get the user’s name and age, the back-end, after receive the data will be added to create and update time and the default password three fields, then save the database.

@RequestMapping("/v1/api/user") @RestController public class UserApi { @Autowired private UserService userService; @PostMapping public User addUser(UserInputDTO userInputDTO){ User user = new User(); user.setUsername(userInputDTO.getUsername()); user.setAge(userInputDTO.getAge()); return userService.addUser(user); }}Copy the code

Let’s just focus on the transformation code in the above code, ignore the rest:

User user = new User();
user.setUsername(userInputDTO.getUsername());
user.setAge(userInputDTO.getAge());
Copy the code

Please use tools

@PostMapping
public User addUser(UserInputDTO userInputDTO){
    User user = new User();
    BeanUtils.copyProperties(userInputDTO,user);

    return userService.addUser(user);
}
Copy the code

Semantics of transformation

The above conversion process, the reader will certainly feel a lot of elegant, but when we write Java code, we need to consider more semantic operations, again look at the above code:

User user = new User();
BeanUtils.copyProperties(userInputDTO,user);
Copy the code

Although this code simplifies and optimizes the code well, there are problems with its semantics. We need to implement a transformation process, so the code is changed as follows:

@PostMapping
 public User addUser(UserInputDTO userInputDTO){
         User user = convertFor(userInputDTO);

         return userService.addUser(user);
 }

 private User convertFor(UserInputDTO userInputDTO){

         User user = new User();
         BeanUtils.copyProperties(userInputDTO,user);
         return user;
 }
Copy the code

This is a better way of writing semantics. Although it is more complicated, it is much more readable. When writing code, we should try to put the same semantic level into a method, for example:

User user = convertFor(userInputDTO);
return userService.addUser(user);
Copy the code

Neither code exposes the implementation, but rather shows how to do a set of semantic operations at the same level within the same method, rather than exposing the implementation.

As mentioned above, it’s a way of refactoring, The reader can refer to Extract Method Refactoring in Martin Fowler’s Refactoring Imporving the Design of Existing Code.

Abstract Interface definition

public interface DTOConvert<S,T> {
    T convert(S s);
}
Copy the code

@RequestMapping("/v1/api/user") @RestController public class UserApi { @Autowired private UserService userService; @PostMapping public User addUser(UserInputDTO userInputDTO){ User user = new UserInputDTOConvert().convert(userInputDTO); return userService.addUser(user); }}Copy the code

review code

If you’re a good Java programmer, I’m sure you’ve reviewed your code several times, as I have. The problem is that you shouldn’t return the User entity directly, because if you do that, you’re exposing too much information about the entity. It’s not safe to return a value like that, so instead you should return a DTO object, We can call it UserOutputDTO:

@PostMapping
public UserOutputDTO addUser(UserInputDTO userInputDTO){
        User user = new UserInputDTOConvert().convert(userInputDTO);
        User saveUserResult = userService.addUser(user);
        UserOutputDTO result = new UserOutDTOConvert().convertToUser(saveUserResult);
        return result;
}
Copy the code

So your API is more robust.

I don’t know if you notice any other problems after reading this code, but as a good Java programmer, take a look at the code we just abstracted: User user = new UserInputDTOConvert().convert(userInputDTO); As you can see, there is no need for a new DTO transform object, and each DTO transform object is generated when it encounters a DTO transform. Therefore, we should consider whether we can aggregate this class and the DTO. public class UserInputDTO { private String username; private int age;

public String getUsername() { return username; } public void setUsername(String username) { this.username = username; } public int getAge() { return age; } public void setAge(int age) { this.age = age; } public User convertToUser(){ UserInputDTOConvert userInputDTOConvert = new UserInputDTOConvert(); User convert = userInputDTOConvert.convert(this); return convert; } private static class UserInputDTOConvert implements DTOConvert<UserInputDTO,User> { @Override public User convert(UserInputDTO userInputDTO) { User user = new User(); BeanUtils.copyProperties(userInputDTO,user); return user; }}}Copy the code

User User = new UserInputDTOConvert().convert(userInputDTO); User saveUserResult = userService.addUser(user);

Becomes: User User = userInputDTO. ConvertToUser (); User saveUserResult = userService.addUser(user);

We added the transformation behavior to the DTO object, which I believe makes the code more readable and semantically correct.

Look again at the utility class

public abstract class Converter<A, B> implements Function<A, B> { protected abstract B doForward(A a); protected abstract A doBackward(B b); //Copy the code

private static class UserInputDTOConvert implements DTOConvert<UserInputDTO,User> { @Override public User convert(UserInputDTO userInputDTO) { User user = new User(); BeanUtils.copyProperties(userInputDTO,user); return user; }}Copy the code

private static class UserInputDTOConvert extends Converter<UserInputDTO, User> { @Override protected User doForward(UserInputDTO userInputDTO) { User user = new User(); BeanUtils.copyProperties(userInputDTO,user); return user; } @Override protected UserInputDTO doBackward(User user) { UserInputDTO userInputDTO = new UserInputDTO(); BeanUtils.copyProperties(user,userInputDTO); return userInputDTO; }}Copy the code

public class UserDTO { private String username; private int age; public String getUsername() { return username; } public void setUsername(String username) { this.username = username; } public int getAge() { return age; } public void setAge(int age) { this.age = age; } public User convertToUser(){ UserDTOConvert userDTOConvert = new UserDTOConvert(); User convert = userDTOConvert.convert(this); return convert; } public UserDTO convertFor(User user){ UserDTOConvert userDTOConvert = new UserDTOConvert(); UserDTO convert = userDTOConvert.reverse().convert(user); return convert; } private static class UserDTOConvert extends Converter<UserDTO, User> { @Override protected User doForward(UserDTO userDTO) { User user = new User(); BeanUtils.copyProperties(userDTO,user); return user; } @Override protected UserDTO doBackward(User user) { UserDTO userDTO = new UserDTO(); BeanUtils.copyProperties(user,userDTO); return userDTO; }}}Copy the code

@PostMapping
 public UserDTO addUser(UserDTO userDTO){
         User user =  userDTO.convertToUser();
         User saveResultUser = userService.addUser(user);
         UserDTO result = userDTO.convertFor(saveResultUser);
         return result;
 }
Copy the code

private static class UserDTOConvert extends Converter<UserDTO, User> { @Override protected User doForward(UserDTO userDTO) { User user = new User(); BeanUtils.copyProperties(userDTO,user); return user; } @override protected UserDTO doBackward(User User) {throw new AssertionError(" Reverse transform methods are not supported!" ); }}Copy the code

The bean validation

If you think the add user API I wrote above is perfect, you are not a good programmer. We should ensure that any data input into the method body is legal.

Why validate

JSR 303 validation

Hibernate provides the JSR 303 implementation, which I think is still very good. I don’t want to tell you how to use it, because you can find a lot of answers on Google! To illustrate, we now check the DTO data:

public class UserDTO { @NotNull private String username; @NotNull private int age; // Other code omitted}Copy the code

API authentication:

@PostMapping
    public UserDTO addUser(@Valid UserDTO userDTO){
            User user =  userDTO.convertToUser();
            User saveResultUser = userService.addUser(user);
            UserDTO result = userDTO.convertFor(saveResultUser);
            return result;
    }
Copy the code

We need to pass the validation results to the front end, and this exception should be converted into an API exception (with an error code).

@PostMapping public UserDTO addUser(@Valid UserDTO userDTO, BindingResult bindingResult){ checkDTOParams(bindingResult);  User user = userDTO.convertToUser(); User saveResultUser = userService.addUser(user); UserDTO result = userDTO.convertFor(saveResultUser); return result; } private void checkDTOParams(BindingResult BindingResult){if(bindingresult.haserrors ()){//throw new validation exception with verification code}}Copy the code

The BindingResult is a result set after Spring MVC validates the DTO. You can refer to Spring’s official documentation

After checking the parameters, you can throw a “validation error exception with a verification code”. For specific exception design, see how to gracefully design Java exceptions

Embrace the lombok

Get rid of setters and getters

In fact, I don’t want to say lombok because there are so many people online, but because many people tell me they don’t even know lombok exists, I’d like to write an example to make it easier for readers:

@Setter @Getter public class UserDTO { @NotNull private String username; @NotNull private int age; public User convertToUser(){ UserDTOConvert userDTOConvert = new UserDTOConvert(); User convert = userDTOConvert.convert(this); return convert; } public UserDTO convertFor(User user){ UserDTOConvert userDTOConvert = new UserDTOConvert(); UserDTO convert = userDTOConvert.reverse().convert(user); return convert; } private static class UserDTOConvert extends Converter<UserDTO, User> { @Override protected User doForward(UserDTO userDTO) { User user = new User(); BeanUtils.copyProperties(userDTO,user); return user; } @override protected UserDTO doBackward(User User) {throw new AssertionError(" Reverse transform methods are not supported!" ); }}}Copy the code

You can see, the annoying getters and setters are gone. But the above example is simply not enough to show lombok’s power. I wanted to write about the use of Lombok that is hard to find on the web, or rarely explained, and about the semantics of the program when it is used. Such as: @ Data, @ AllArgsConstructor, @ NoArgsConstructor.. These I will not carry on a description, please inquire information by yourself.

Chain style in beans

public class Student { private String name; private int age; public String getName() { return name; } public Student setName(String name) { this.name = name; return this; } public int getAge() { return age; } public Student setAge(int age) { return this; }}Copy the code

Student student = new Student()
        .setAge(24)
        .setName("zs");
Copy the code

@Accessors(chain = true)
@Setter
@Getter
public class Student {
    private String name;
    private int age;
}
Copy the code

Static constructor

Static constructors are really more semantic and simpler than just new an object. For example, new a List object, used like this:

List<String> list = new ArrayList<>();
Copy the code

Take a look at the creation in Guava:

List<String> list = Lists.newArrayList();
Copy the code

Lists naming is a convention (as the saying goes: Lists are a utility class of List. Is it more straightforward to use List’s utility class to generate Lists than to create a new subclass? Have you figured out a way to create a Map?

HashMap<String, String> objectObjectHashMap = Maps.newHashMap();
Copy the code

Well, if you understand the semantics I’m talking about, then you’re one step closer to becoming a Java programmer.

If you go back to Student, a lot of times when you’re writing Student beans, you’re going to have fields that you have to enter, like the name field in Student, and you’re going to wrap the name field as a constructor, and you’re just going to pass in the name constructor, To create a Student object.

Using Lombok, add the above static constructor and the required constructor to the following (@requiredargsconstructor and @nonnull) :

@Accessors(chain = true) @Setter @Getter @RequiredArgsConstructor(staticName = "ofName") public class Student { @NonNull  private String name; private int age; }Copy the code

Test code:

Student student = Student.ofName("zs");
Copy the code

Is the resulting bean semantic better than simply new a constructor with parameters (including the name constructor)?

Of course, after reading a lot of the source code, I’d like to believe that replacing the static constructor ofName with of would be much cleaner first:

@Accessors(chain = true)
@Setter
@Getter
@RequiredArgsConstructor(staticName = "of")
public class Student {
        @NonNull private String name;
        private int age;
}
Copy the code

Test code:

Student student = Student.of("zs");
Copy the code

Of course, he still supports chain calls:

Student student = Student.of("zs").setAge(24);
Copy the code

It’s really neat and readable to write code like this.

Using a builder

public class Student { private String name; private int age; public String getName() { return name; } public void setName(String name) { this.name = name; } public int getAge() { return age; } public void setAge(int age) { this.age = age; } public static Builder builder(){ return new Builder(); } public static class Builder{ private String name; private int age; public Builder name(String name){ this.name = name; return this; } public Builder age(int age){ this.age = age; return this; } public Student build(){ Student student = new Student(); student.setAge(age); student.setName(name); return student; }}}Copy the code

Student student = Student.builder().name("zs").age(24).build();
Copy the code

@Builder
public class Student {
    private String name;
    private int age;
}
Copy the code

Student student = Student.builder().name("zs").age(24).build();
Copy the code

The proxy pattern

As we all know, invoking rest interfaces in programs is a common behavioral action, and if you’ve used Spring’s RestTemplate as I have, I’m sure you’ll find the non-HTTP status code exceptions it throws as distastefully as I do.

So let’s consider designing the RestTemplate wrapper for the lowest level wrapper pattern:

public abstract class FilterRestTemplate implements RestOperations { protected volatile RestTemplate restTemplate; protected FilterRestTemplate(RestTemplate restTemplate){ this.restTemplate = restTemplate; } // Implement all interfaces of RestOperations}Copy the code

The FilterRestTemplate is then wrapped and extended by the extension class:

public class ExtractRestTemplate extends FilterRestTemplate { private RestTemplate restTemplate; public ExtractRestTemplate(RestTemplate restTemplate) { super(restTemplate); this.restTemplate = restTemplate; } public <T> RestResponseDTO<T> postForEntityWithNoException(String url, Object request, Class<T> responseType, Object... uriVariables) throws RestClientException { RestResponseDTO<T> restResponseDTO = new RestResponseDTO<T>(); ResponseEntity<T> tResponseEntity; try { tResponseEntity = restTemplate.postForEntity(url, request, responseType, uriVariables); restResponseDTO.setData(tResponseEntity.getBody()); restResponseDTO.setMessage(tResponseEntity.getStatusCode().name()); restResponseDTO.setStatusCode(tResponseEntity.getStatusCodeValue()); }catch (Exception e){ restResponseDTO.setStatusCode(RestResponseDTO.UNKNOWN_ERROR); restResponseDTO.setMessage(e.getMessage()); restResponseDTO.setData(null); } return restResponseDTO; }}Copy the code

The ExtractRestTemplate wrapper nicely changes the exception throwing behavior to make the program more fault tolerant. Instead of thinking about the ExtractRestTemplate, let’s focus on the FilterRestTemplate, “Implement all interfaces to RestOperations.” This operation is by no means a write-off. I wrote for almost half an hour before refactoring, as follows:

public abstract class FilterRestTemplate implements RestOperations { protected volatile RestTemplate restTemplate; protected FilterRestTemplate(RestTemplate restTemplate) { this.restTemplate = restTemplate; } @Override public <T> T getForObject(String url, Class<T> responseType, Object... uriVariables) throws RestClientException { return restTemplate.getForObject(url,responseType,uriVariables); } @Override public <T> T getForObject(String url, Class<T> responseType, Map<String, ? > uriVariables) throws RestClientException { return restTemplate.getForObject(url,responseType,uriVariables); } @Override public <T> T getForObject(URI url, Class<T> responseType) throws RestClientException { return restTemplate.getForObject(url,responseType); } @Override public <T> ResponseEntity<T> getForEntity(String url, Class<T> responseType, Object... uriVariables) throws RestClientException { return restTemplate.getForEntity(url,responseType,uriVariables); } // Other implementation code is omitted... }Copy the code

I’m sure you’ll feel as sick to your stomach as I did when I optimized my code (@delegate) with lombok’s proxy annotations:

@AllArgsConstructor
public abstract class FilterRestTemplate implements RestOperations {
    @Delegate
    protected volatile RestTemplate restTemplate;
}
Copy the code

These lines of code completely replace the verbose code above. Isn’t it simple? Be a programmer who embraces Lombok.

refactoring

Demand case

The project requirements

Thinking and reconstruction

I believe this requirement seems simple enough to accomplish no matter how it is written.

Many people might see this requirement and start writing Calendar or Date calculations to complete the requirement.

My advice is to think carefully about how to write code and then write it, not to use Calendar or Date for all time manipulation, but to depend on the scene.

For time calculation we should consider a similar mature time calculation framework such as Joda-time to write code, which makes the code more concise and readable.

Please consider how this requirement can be accomplished in Java code first, or write an idea of how you think this code can be accomplished, and then take a look at my code below, so that you can learn more:

Final DateTime DISTRIBUTION_TIME_SPLIT_TIME = new DateTime().withtime (15,0,0,0); private Date calculateDistributionTimeByOrderCreateTime(Date orderCreateTime){ DateTime orderCreateDateTime = new DateTime(orderCreateTime); Date tomorrow = orderCreateDateTime.plusDays(1).toDate(); Date theDayAfterTomorrow = orderCreateDateTime.plusDays(2).toDate(); return orderCreateDateTime.isAfter(DISTRIBUTION_TIME_SPLIT_TIME) ? wrapDistributionTime(theDayAfterTomorrow) : wrapDistributionTime(tomorrow); } private Date wrapDistributionTime(Date distributionTime){ DateTime currentDistributionDateTime = new DateTime(distributionTime); DateTime plusOneDay = currentDistributionDateTime.plusDays(1); boolean isSunday = (DateTimeConstants.SUNDAY == currentDistributionDateTime.getDayOfWeek()); return isSunday ? plusOneDay.toDate() : currentDistributionDateTime.toDate() ; }Copy the code

When you read this code, you will find that I treat the judgment and different possible results as a variable, and finally make a trinary operator to return, so elegant and readable is obvious, of course, this code is not overnight, I optimized the above code generated three times. Readers can compare their own code with the code I wrote.

Improve the method

Design patterns

Design patterns are tools, not indicators of whether or not you are a good programmer.

I often see a programmer Shouting excitedly, which program I used the design pattern at which point, how good, how good. When I looked through it, I found a lot of it was over-engineered.

Service driven technologies or technologies drive services

Code design

I’ve been working on the Java back end, and there’s been a lot of change, as I’m sure you’ve all experienced.

For example, when we write a piece of code, we think about mapping the requirements to the code’s state pattern, and then one day, the state pattern adds a lot of behavior changes, and then you’re left scratching your head. You just add too many behaviors and changes to the state pattern.

Over time, you’ll realize that these state patterns are actually more like clusters of algorithms, and that you should be using strategy patterns, by which time you’ll have lost your head.

All I’m saying is, change the state mode to the policy mode whenever it makes sense to you. All modes are not imaginary, they are based on refactoring.

There is no silver bullet in Java programming, embrace business change, always think about refactoring, and you’ll have a better code design!

Are you really good?

skills

UML

clean code

In my opinion, keeping code concise and readable is the most basic guarantee of code, and I think it is forgivable if these two things are compromised for the sake of program efficiency. Besides, there is no excuse for squandering your code.

1. Check out Clean Code by Robert C. Martin
2. Please refer to the Meituan article to talk about clean Code
3. Also take a look at Ali’s Java coding specification

No matter what, keep your code clean.

Linux Basic Commands

conclusion

Java is a big system, and today’s discussion is not about frameworks and architecture, just how to write good code.

This article explains how to write a good Java program from the small aspects all the way to the big aspects, and tells readers how to improve their coding level.

I hope everyone reading this becomes a good Java programmer.