Four tips for summarizing Java code writing

This article brings you the content is about summarizing Java code Writing four skills, there is a certain reference value, the need for friends can refer to, I hope to help you.

Our usual programming task is to apply the same technology suite to different projects, and for the most part, these technologies can meet the goals. However, some projects may require some special techniques, so engineers have to delve into the simplest but most effective way to find out. In this article, we will introduce some common design strategies and target implementation techniques that can help solve common problems, namely:

1. Only purposeful optimization.

2. Constants use enumerations as much as possible

3. Use polymorphism as much as possible

It is important to note that the techniques described in this article do not apply to all situations. In addition, when and where these technologies should be used, they need to be considered by the user.

1. Only purposeful optimization

Large software systems are definitely concerned with performance issues. Although we want to be able to write the most efficient code, many times, if we want to optimize the code, we can not do it. For example, does the following code affect performance?

public void processintegers (list<integer> integers) {for (Integer value:integers) {for    (int i = Integers.size ( )-1; I >= 0; i--) {        value + = Integers.get (i);}}    }

This is subject to the circumstances. The above code shows that its processing algorithm is O (n³) (using the large o symbol), where n is the size of the list collection. If n is only 5, then there will be no problem and only 25 iterations will be performed. But if n is 100,000, that might affect performance. Please note that even then we cannot determine that there are certain problems. Although this method needs to perform 1 billion logical iterations, it remains to be seen whether the performance impact will occur.

For example, assuming that the client executes this code in its own thread and waits for the computation to complete asynchronously, its execution time may be acceptable. Similarly, if the system is deployed in a production environment, but no client calls, there is no need to optimize the code because it does not consume the overall performance of the system at all. In fact, the system becomes more complex after optimizing performance, and the tragedy is that the performance of the system does not improve.

The most important thing is that there is no free lunch, so in order to reduce the cost, we usually use a technique similar to caching, cyclic expansion, or expected value to achieve optimization, which increases the complexity of the system and reduces the readability of the code. If this optimization can improve the performance of the system, even if it becomes complex, it is worthwhile, but before making a decision, you must first know these two messages:

1. What are the performance requirements

2. Where are the performance bottlenecks?

First, we need to know exactly what the performance requirements are. If the end result is within the requirements and the end user does not raise any objections, then there is no need for performance optimization. However, when a new feature is added or the amount of data on the system reaches a certain scale, it must be optimized, otherwise problems may occur.

In this case, it should not rely on intuition, nor should it rely on censorship. Because even experienced developers like Martin Fowler are prone to do some wrong optimizations, as explained in the refactoring (page 70th) article:

If you analyze enough programs, you'll find that the interesting thing about performance is that most of the time is wasted in a fraction of the code in the system. If the same optimizations were made for all the code, the end result would be to waste 90% of the optimizations, since the code that was optimized would not run much more frequently. The time it takes to optimize for no purpose is a waste of time.

As a seasoned developer, we should take this view seriously. The first guess not only did not improve the performance of the system, but 90% of the development time is completely wasted. Instead, we should perform common use cases in a production environment (or in a pre-production environment) and find out which part of the process is consuming system resources and then configuring the system. For example, the code that consumes most of the resources accounts for only 10%, so optimizing the remaining 90% of the code is a waste of time.

Based on the results of the analysis, we should start with the most common situations in order to use this knowledge. Because this will ensure that the actual effort is ultimately able to improve the performance of the system. After each optimization, the analysis steps should be repeated. Because this not only ensures that the performance of the system is really improved, but also that after the system is optimized, the performance bottleneck is in which part (because after a bottleneck is resolved, other bottlenecks may consume more of the overall resources of the system). It is important to note that the percentage of time spent in existing bottlenecks is likely to increase as the remaining bottlenecks are temporary and the overall execution time should be reduced as the target bottleneck is eliminated.

While it takes a lot of capacity to do a full review of the profile in a Java system, there are some common tools that can help you discover the performance hotspots of your system, including JMeter, AppDynamics, and Yourkit. Also, refer to the Dzone Performance Monitoring Guide for more information on Java program Performance optimizations.

While performance is a very important part of many large software systems, it is also part of the automated test suite in the product delivery pipeline, but it cannot be optimized blindly and without purpose. Instead, specific optimizations should be made to the performance bottlenecks already mastered. Not only does this help us avoid adding complexity to the system, but it also allows us to take fewer detours and not do the time-wasting optimizations.

2. Constants use enumerations as much as possible

There are many scenarios that require users to list a set of  or constant values, such as HTTP response codes that may be encountered in a Web application. One of the most common implementation techniques is to create a new class that has a number of static final type values, each of which should have a comment that describes what the value means:

public class Httpresponsecodes {public static final int OK = 200;public static final int not_found = 404;public static fin Al int FORBIDDEN = 403;} if (Gethttpresponse (). Getstatuscode () = = Httpresponsecodes.ok) {//do something if the response code is OK}

It's good to have this idea, but there are some drawbacks:

No strict validation of incoming integer values
The method on the status code cannot be called because it is a basic data type
In the first case, simply creating a specific represented represents a special integer value, but there is no restriction on the method or variable, so the value used may exceed the defined range. For example:

public class Httpresponsehandler {public static void printmessage (int statusCode) {    System.out.println ("recieved Status of "+ StatusCode);}}

Httpresponsehandler.printmessage (15000);
Although 15000 is not a valid HTTP response code, there is no restriction on the server side that the client must provide a valid integer. In the second case, we have no way to define the method for the status code. For example, if you want to check whether a given status code is a successful code, you must define a separate function:

public class Httpresponsecodes {public static final int OK = 200;public static final int not_found = 404;public static fin Al int FORBIDDEN = 403;public static Boolean issuccess (int statusCode) {    return statusCode >= && status Code < 300; }}if (Httpresponsecodes.issuccess (Gethttpresponse (). Getstatuscode ())) {//do something if the response code is a success C ODE}

To solve these problems, we need to change the constant type from the base data type to the custom type and allow only the specific objects of the custom class. This is the purpose of the Java Enumeration (enum). With enum, we can solve both of these problems at once:

public enum Httpresponsecodes {OK ($), FORBIDDEN (403), Not_found (404);p rivate final int code; Httpresponsecodes (int code) {    this.code = code;} public int GetCode () {    return code;} public Boolean issuccess () {    return code >= && code < 300;}} if (Gethttpresponse (). Getstatuscode (). Issuccess ()) {//do something if the response code is a success code}

Again, it is now possible to require that a valid status code be provided when the method is called:

public class Httpresponsehandler {public static void Printmessage (Httpresponsecode statusCode) {    System.out.println ("Recieved status of" + Statuscode.getcode ());}}

Httpresponsehandler.printmessage (Httpresponsecode.ok);
It is worth noting that this example shows that if you are a constant, you should use enumerations as much as possible, but not that you should use enumerations. In some cases, you might want to use a constant to represent a particular value, but it also allows you to provide additional values. For example, we may all know that pi, we can use a constant to capture this value (and reuse it):

public class Numericconstants {public static final double PI = 3.14;public static final double unit_circle_area = pi * PI; }public class Rug {Private Final Double Area;public class Run (double area) {    This.area = area;} Public double Getcost () {    return area * 2;}} Create a carpet that's 4 feet in diameter (radius of 2 feet) Rug fourfootrug = new Rug (2 * numericconstants.unit_circle _area);

Therefore, the rules that use enumerations can be summed up as:

When all possible discrete values have been known in advance, you can use the enumeration

Taking the HTTP response code mentioned above as an example, we may know all the values of the HTTP status code (which can be found in RFC 7231, which defines the HTTP 1.1 protocol). Therefore, an enumeration is used. In the case of pi, we do not know all possible values of pi (any possible double is valid), but at the same time want to create a constant for the circular rugs, making the calculation easier (easier to read), and therefore defining a series of constants.

If you don't know all the possible values in advance, but want to include a field or method for each value, the simplest way is to create a new class to represent the data. Although it is not said that the scenario should absolutely not enumerate, the key to knowing where and when not to use the enumeration is to be aware of all the values in advance and prohibit any other values.

the Equals () method inside the class

Object recognition can be a difficult problem: if two objects occupy the same position in memory, are they the same? If they have the same ID, are they the same? or if all the fields are equal? Although each class has its own identity logic, But there are many Western countries in the system that need to determine whether they are equal. For example, like the next class, which represents order purchase ...

public class Purchase {private long Id;public long getId () {    return ID;} public void SetId (long id) {    this.id = ID;}}

...... As written below, there must be many places in the code that are similar:

Purchase originalpurchase = new Purchase ();  Purchase updatedpurchase = new Purchase (); if (originalpurchase.getid () = = Updatedpurchase.getid ()) {//Execute some logic For equal purchases}

The more these logical calls are (in turn, against the dry principle), the identity information of the purchase class becomes more and more. If, for some reason, the identity logic of the purchase class is changed (for example, by changing the type of the identifier), there must be a lot more where the identity logic needs to be updated.

We should initialize this logic within the class, rather than propagating the identity logic of the purchase class too much through the system. At first glance, we can create a new method, such as Issame, which is an purchase object, and compares the IDs of each object to see if they are the same:

public class Purchase {private Long Id;public Boolean issame (Purchase other) {    return getId () = = Other.gerid ();}   }

Although this is an effective solution, it ignores the built-in functionality of Java: Using the Equals method. Each class in Java inherits the object class, which, although implicit, inherits the Equals method. By default, this method checks the object identity (the same object in memory), as shown in the following code snippet in the object class definition (version 1.8.0_131) in the JDK:

public boolean equals (Object obj) {return (this = = obj);}

This equals method acts as a natural place to inject identity logic (by overriding the default equals implementation):

public class Purchase {private long Id;public long getId () {    return ID;} public void SetId (long id) {    this.id = ID;} @Overridepublic Boolean equals (Object) {    if (this = other) {        return true;    }    else if (! ( Other instanceof Purchase) {        return false;    }    else {        return ((Purchase) other). GetId () = = GetId ();}}    

Although this equals method looks complicated, we only need to consider three cases because the Equals method accepts only the parameters of the type object:

Another object is the current object (that is, Originalpurchase.equals (originalpurchase)), which, by definition, is the same object and therefore returns true

The other object is not a purchase object, in which case we cannot compare the purchase ID, so the two objects are not equal

Other objects are not the same object, but are instances of purchase, so equality depends on whether the ID of the current purchase and the other purchase are equal

We can now refactor our previous conditions, as follows:

Purchase originalpurchase = new Purchase (); Purchase updatedpurchase = new Purchase (); if (Originalpurchase.equals (updatedpurchase)) {//Execute some logic for equal P Urchases}

In addition to reducing replication in the system, there are other advantages to refactoring the default Equals method. For example, if you construct a list of purchase objects and check if the list contains another purchase object with the same ID (different objects in memory), then we get a true value because the two values are considered equal:

List<purchase> purchases = new arraylist<> ();p urchases.add (originalpurchase);p urchases.contains ( Updatedpurchase); True

In general, wherever you need to determine whether two classes are equal, you only need to use the overridden Equals method. If you want to judge equality by using the Equals method implicitly with inherited object objects, we can also use the = = operator, as follows:

if (originalpurchase = = updatedpurchase) {//The objects is the same objects in memory}

It is also important to note that the Hashcode method should be overridden when the Equals method is overridden. For more information about the relationship between the two methods, and how to correctly define the Hashcode method, see this thread.

As we can see, overriding the Equals method not only initializes the identity logic within the class, but reduces the proliferation of this logic throughout the system, it also allows the Java language to make informed decisions about the class.

4. Use polymorphism as much as possible

For any programming language, conditional sentences are a very common structure, and there are certain reasons for its existence. Because different combinations can allow the user to change the behavior of the system based on the given value or the instantaneous state of the object. Assuming that the user needs to calculate the balance of each bank account, the following code can be developed:

public enum Bankaccounttype {checking,savings,certificate_of_deposit;} public class BankAccount {private final bankaccounttype type;public BankAccount (bankaccounttype type) {    This.type = t ype;} Public double getinterestrate () {    switch (type) {case        CHECKING:            return 0.03;//3% case        SAVINGS:            return 0.04; 4% case        certificate_of_deposit:            return 0.05;//5%        default:            throw new Unsupportedoperationexception ();    }} public Boolean supportsdeposits () {    switch (type) {case        CHECKING:            return true;        Case SAVINGS:            return true;        Case Certificate_of_deposit:            return false;        Default:            throw new Unsupportedoperationexception ();}}}    

Although the above code satisfies the basic requirements, there is an obvious flaw: the user simply determines the behavior of the system based on the type of account given. This not only requires the user to check the account type each time they make a decision, but also to repeat the logic when making a decision. For example, in the above design, the user must be checked in both ways. This can lead to runaway situations, especially when the need to add new account types is received.

We can use polymorphism to make decisions implicitly, rather than using account types to differentiate between them. To do this, we convert the specific class of bankaccount into an interface and pass the decision-making process into a series of specific classes that represent each type of bank account:

Public interface BankAccount {public double getinterestrate ();p ublic boolean supportsdeposits ();} public class Checkingaccount implements BankAccount {@Overridepublic double getintestrate () {    return 0.03;} @Overridepublic Boolean supportsdeposits () {    return true;}} public class SavingsAccount implements BankAccount {@Overridepublic double getintestrate () {    return 0.04;} @Overridepublic Boolean supportsdeposits () {    return true;}} public class Certificateofdepositaccount implements BankAccount {@Overridepublic double getintestrate () {    return 0.05;} @Overridepublic Boolean supportsdeposits () {    return false;}}

This not only encapsulates the information specific to each account into its own class, but also enables users to change the design in two important ways. First of all, if you want to add a new bank account type, just create a new concrete class, implement the BankAccount interface, give two methods to implement the specific implementation. In a conditional structure design, we must add a new value to the enumeration, add a new case statement to the two methods, and insert the logic for the new account under each cases statement.

Second, if we want to add a new method to the BankAccount interface, we just need to add a new method to each specific class. In the conditional design, we must copy the existing switch statement and add it to our new method. In addition, we must add the logic for each account type in each case statement.

Mathematically, when we create a new method or add a new type, we must make the same number of logical changes in the polymorphic and conditional designs. For example, if we add a new method to a polymorphic design, we must add the new method to the specific class of all n bank accounts, and in the conditional design, we must add n new case statements in our new method. If we add a new account type to the polymorphic design, we must implement all the M numbers in the BankAccount interface, and in the conditional design, we must add a new case statement to each m existing method.

Although the number of changes we have to make is equal, the nature of the change is completely different. In a polymorphic design, if we add a new account type and forget to include a method, the compiler throws an error because we do not implement all the methods in our BankAccount interface. In a conditional design, there is no such check to ensure that each type has a case statement. If you add a new type, we can simply forget to update each switch statement. The more serious the problem is, the more we repeat our switch statement. We are human, and we tend to make mistakes. So, whenever we can rely on the compiler to remind us of the error, we should do so.

The second important consideration with respect to both designs is that they are externally equivalent. For example, if we want to check the interest rate for a checking account, the condition design would look like this:

BankAccount checkingaccount = new BankAccount (bankaccounttype.checking); System.out.println (Checkingaccount.getinterestrate ()); output:0.03

Instead, the polymorphic design would look similar to the following:

BankAccount checkingaccount = new Checkingaccount (); System.out.println (Checkingaccount.getinterestrate ()); output:0.03

From an external point of view, we just call Getintereunk () on the BankAccount object. If we were to abstract the creation process into a factory class, it would be more obvious:

public class Conditionalaccountfactory {public static BankAccount Createcheckingaccount () {     return new BankAccount ( bankaccounttype.checking);}} public class Polymorphicaccountfactory {public static BankAccount Createcheckingaccount () {     return new Checkingaccount ();}} In both cases, we create the accounts using a factorybankaccount Conditionalcheckingaccount = conditionalaccountfactory . Createcheckingaccount (); BankAccount Polymorphiccheckingaccount = Polymorphicaccountfactory.createcheckingaccount ();//In both cases, the To obtain the interest rate is the SAMESYSTEM.OUT.PRINTLN (Conditionalcheckingaccount.getinterestrate ()); Output:0.03system.out.println (Polymorphiccheckingaccount.getinterestrate ()); output:0.03

Replacing conditional logic with polymorphic classes is very common, so the method of refactoring conditional statements into polymorphic classes has been published. Here is a simple example. In addition, Martin Fowler Martin Fowler's refactoring (see page 255) also describes the detailed process of performing this refactoring.

As with other techniques in this article, there is no hard rule as to when to perform transition from conditional logic to polymorphic classes. In fact, we do not recommend the use of such cases. In a test-driven design: For example, Kent Beck designed a simple currency system to use polymorphic classes, but found that it made the design too complex, and then redesigned his design into a non-polymorphic style. Experience and reasonable judgment will determine when the conditional code is converted to polymorphic code at the appropriate time.

Conclusion

As programmers, although the usual techniques used to solve most of the problems, sometimes we should break this routine and proactively demand some innovation. After all, as a developer, expanding the breadth and depth of your knowledge will not only allow us to make smarter decisions, but also make us smarter.