Author:Admin
RecentStephen SchmidtIn my blog, I published 《Next-generation Java programming styleOfArticleHe elaborated on the changes in the Java programming style in his eyes and the future trend: many companies and developers are switching from Java to otherProgramming Language: Ruby, Python, groovy, Erlang, or Scala. However, you may not be able to do this. Even so, you can change your programming style and obtain the advantages of these new languages. In fact, the Java programming style has changed significantly over the past 15 years.
In this article, Stephen puts forward the following points:
- Mark final as much as possible:To make everything immutable, marking a variable as final can prevent it from changing its value. A bug is often introduced when you assign a value to a variable. You should use a new variable. In addition, final can improveCodeReadability. I have also written an article on this topic :《All variables in Java should be final"
-
- No setter:Many JavaProgramThe user will naturally add setter to all fields in the class. Think about it. Is it true that every field needs to be modified? A better way is to create a new object that contains the changed state. In addition, we also try to remove getter, and we should follow the"Tell, don't ask.
- avoid using loops to operate the list: For the experience gained from functional programming, loops are not the best way to perform set operations. For example, we can use Google collections provided filter function.
predicate candrinkbeer = new predicate () {public Boolean apply (hasage) {return hasage. isolderthan (16) ;}}; list
beerdrinkers = filter (persons, candrinkbeer);
- Use a single line of code:Java is a complicated (noisy) language. We should write more precise code. Write the code as one line. For example:
Public int add (int A, int B) {return a + B ;}
-
- A large number of interfaces are used:Domain-driven design is already widely used. One should be divided into multiple "Roles", that is, multiple interfaces should be implemented to improve the degree of reuse. Methods should be oriented to "Roles" rather than specific classes. In 《Do not use string in JavaThis article discusses more about this.
- Erlang-style concurrency: JAVA concurrency features (such as lock and synchronized) are too low-end and difficult to use. Erlang-style concurrency is a better method. akka and actorom . In addition, you can use join/fork in Java. util. Concurrent and data structure for programming.
- Use fluent interface:Fluent interface can make the code shorter and easier to write. Mapmaker in Google collections is a good example:
Concurrentmap graphs = new mapmaker (). concurrencylevel (32 ). softkeys (). weakvalues (). expiration (30, timeunit. minutes ). makecomputingmap (new function () {public graph apply (Key key) {return createexpensivegraph (key );}});
-
- Avoid creating getter and Setter in DTO:If you have a simple DTO (data transfer object), don't bother writing getter and setter. Use public fields directly. However, when you cannot fully control the use of the Code, be careful.
After this article is published, many people have different opinions. WhereCedric otakuPublished the article 《The next generation of Java is similar to today'sAnd opposed most of the ideas put forward by Stephen.
-
- Final as much as possible:Too many final statements can reduce the readability of the code, and it cannot provide additional benefits for the code. I don't remember the last time the variable was assigned a value. It is worth mentioning that marking final on members other than the field violates Google's style guide.
- Avoid setter:It looks good, but it is unrealistic. Sometimes you do not want to pass all parameters through the constructor. In addition, if you use an object pool, variable objects make programming easier. Stephen is not the first person to propose to remove the accessor from OO programming.Obviously not feasible.
-
- Avoid loops:Java is not suitable for functional programming, So I think predicate code is hard to understand. I guess most Java programmers will agree with me, even if they are familiar with the closure style.
-
- Single line code:This depends on the situation. Introducing temporary variables to split an expression can improve code readability and easily set breakpoints for it.
-
- Interface:Good advice, but not overdo it. I used to argue over similar topics, but too many interfaces will lead to small types of explosion, blurring your high-end type intent.
- Erlang parallel style:I reiterate that using programming styles other than Java design is a dangerous practice. Java. util. Concurrent contains very useful functions. I have encountered many Java abstractions based on these elements, which are superior to the Erlang actor architecture.
-
- Fluent interface:This suggestion is interesting. It is contrary to another suggestion put forward by Stephen "avoid setter. Another form of Setter in fluent interface, isn't it?
-
- Use public fields:No, never do this. You will not regret adding an accesser, But I can ensure that you will regret using public fields because of laziness.
After Cedric's article, Stephen added his statement:
Without setter, you cannot modify this object. I just say that the pure setter is not an object-oriented way of thinking. For example, Which of the following is better for stop () and setstop (true?
(For predicate code that is not easy to read) I think your assumptions are incorrect. Loop is a "procedural" code, while predicate is an encapsulated, reusable, and easy-to-understand "object ". There is no functional programming here. Here is pure oo-I mentioned FP just because I "introduced" This method from there.
There are also many people who have commented on articles by Stephen on and Cedric. For example, some people support Stephen's point of view and believe that final can better express the intent of the Code. Some people even suggested:
the simpler solution is to use Scala-Immutable state and unified access principles (fields, attributes, and methods look the same), single-line code, use monads or functions to replace loops ...... These features have been fully embodied in Scala.
reference address
http://java.csdn.net/index.php/2009/08/19/%e7%83%ad%e7%82%b9%e8% AE %a8%e8% AE %ba%ef%bc%9ajava%e7%bc%96%e7%a8%8b%e9%a3%8e%e6%a0%bc%e7%9a%84%e6%94%b9%e5%8f%98/