Java programming common "pit" summary (next) __ algorithm

Java programming common "pit" summary (next) 30. Misuse of List

It is recommended that the following scenarios replace the list with array:

1.list length fixed, e.g. every day of the week

2. Frequent traversal of the list, such as over 1w times

3. Need to pack the numbers (the main JDK does not provide a basic type of list)

For example, the following code.

Wrong wording:

list<integer> codes = new arraylist<integer> ();
Codes.add (integer.valueof (10));
Codes.add (Integer.valueof (20));
Codes.add (integer.valueof (30));
Codes.add (Integer.valueof (40));

The correct wording:

Int[] codes = {10, 20, 30, 40};

Wrong wording:

Horribly slow and a memory waster if L has a few thousand elements (try it yourself!)
List<mergeable> L = ...;
for (int i=0 i < l.size ()-1; i++) {
mergeable one = L.get (i);
Iterator<mergeable> j = l.iterator (i+1); Memory allocation!
while (J.hasnext ()) {
mergeable other = L.next ();
if (One.canmergewith (other)) {
One.merge (other);
Other.remove ();
}
}
}

The correct wording:

Quite fast and no memory allocation
mergeable[] L = ...;
for (int i=0 i < l.length-1; i++) {
Mergeable one = L[i];
for (int j=i+1 J < L.length; J + +) {
mergeable other = L[j];
if (One.canmergewith (other)) {
One.merge (other);
L[J] = null;
}
}
}

Sun also realizes this, so in the JDK, Collections.sort () is copying a list into an array and then calling the Arrays.sort method to perform the sort. 31. Use an array to describe a structure

Error usage:

/**
* @returns [1]: Location, [2]: Customer, [3]: Incident
*/
Object[] getdetails (int id) {...

This describes the return value of a method in the form of an array + document. Although very simple, but easy to misuse, the correct approach should be to define a class.

The correct wording:

Details getdetails (int id) {...}
Private class Details {
Public Location Location;
Public customer customer;
Public Incident Incident;
}

32. Excessive restrictions on methods

Error usage:

public void Notify (person p) {
...
SendMail (P.getname (), P.getfirstname (), P.getemail ());
...
}
Class Phonebook {
String Lookup (String employeeId) {
Employee emp = ...
return Emp.getphone ();
}
}

The first example is to limit the method parameters too much, and the second example has too many restrictions on the return value of the method.

The correct wording:

public void Notify (person p) {
...
SendMail (P);
...
}
Class Employeedirectory {
Employee lookup (String employeeId) {
Employee emp = ...
return EMP;
}
}

33. The Pojo setter method is superfluous

Wrong wording:

private String name;
public void SetName (String name) {
THIS.name = Name.trim ();
}
public void String GetName () {
return this.name;
}

Sometimes we hate the fact that strings appear at the end of the string, so trim is done in the setter method, but the side effects of this result are inconsistent with the return value of the Getter method and the setter method, if only javabean as a data container, Then it's best not to include any business logic. The business logic is handled in a specialized business layer or in the control layer.

The right approach:

Person.setname (Textinput.gettext (). Trim ());

34.SimpleDateFormat Non-threading security misuse

Wrong wording:

public class Constants {
public static final SimpleDateFormat date = new SimpleDateFormat ("DD. Mm.yyyy ");
}

SimpleDateFormat is not thread-safe. In the case of multithreading parallel processing, you get unexpected values. This error is very common! If you really want to be in a multi-threaded environment common to the same simpledateformat, then do a good job of synchronization (cache flush, lock contention), but this will make more complex, not as direct new a reality.

35. Using global parameters to configure constant classes/interfaces

Public interface Constants {
String Version = "1.0";
String DateFormat = "dd. Mm.yyyy ";
String configfile = ". APPRC";
int maxnamelength = 32;
String somequery = "SELECT * From ...";
}

Many applications will define such a global constant class or interface, but why is this practice not recommended? Because there is basically no association between these constants, they are only defined together because they are common. However, if other components need to use these global variables, you must have a dependency on the constant class, especially if there is a scenario for server and remote client invocation.