A Regular Expression HashMap Implementation in Java

Below is an implementation of a Regular Expression HashMap. It works with key-value pairs which the key is a regular expression. It compiles the key (regular expression) while adding (i.e. putting), so there is no compile time while getting. Once getting an element, you don't give regular expression; you give any possible value of a regular expression. 

As a result, this behaviour provides to map numerous values of a regular expression into the same value. The class does not depend to any external libraries, uses only default java.util. So, it will be used simply when a behaviour like that is required. 

1. import java.util.ArrayList;
2. import java.util.HashMap;
3. import java.util.regex.Pattern;
5. /**
6.  * This class is an extended version of Java HashMap
7.  * and includes pattern-value lists which are used to
8.  * evaluate regular expression values. If given item
9.  * is a regular expression, it is saved in regexp lists.
10.  * If requested item matches with a regular expression,
11.  * its value is get from regexp lists.
12.  *
13.  * @author cb
14.  *
15.  * @param <K> : Key of the map item.
16.  * @param <V> : Value of the map item.
17.  */
18. public class RegExHashMap<K, V> extends HashMap<K, V> {
20.     // list of regular expression patterns
21.     private ArrayList<Pattern> regExPatterns = new ArrayList<Pattern>();
22.     // list of regular expression values which match patterns
23.     private ArrayList<V> regExValues = new ArrayList<V>();
25.     /**
26.      * Compile regular expression and add it to the regexp list as key.
27.      */
28.     @Override
29.     public V put(K key, V value) {
30.        
31.         regExPatterns.add(Pattern.compile(key.toString()));
32.         regExValues.add(value);
33.         return value;
34.     }
36.     /**
37.      * If requested value matches with a regular expression,
38.      * returns it from regexp lists.
39.      */
40.     @Override
41.     public V get(Object key) {
43.         CharSequence cs = new String(key.toString());
44.        
45.         for (int i = 0; i < regExPatterns.size(); i++) {
46.             if (regExPatterns.get(i).matcher(cs).matches()) {
47.                
48.                 return regExValues.get(i);
49.             }
50.         }
51.         return super.get(key);
52.     }
53. }

10 Best Practices of Code Commenting & Formatting

Code commenting and formatting are all about code understandability. Code understandability is very relevant to code maintainability. So, small details about programming may help maintainability. In this context, some practices about commenting and formatting will be told here:

Commenting

Comments may be thought as part of the code, so they are really important. E.g. a commentless code library will be useless in a short time with high probability. Even though there are some approaches which suggests self-documenting code over code documentation, we suggest (self-documenting code + code documentation).

1. Use comments "as required". 
• Unnecessary over-commenting in each line will reduce readability:
• int count = 0; // assigning zero as initial value to the count (?!?)
• Lack of commenting will increase maintenance time. Also, variable/method names should be understandable and self commenting
• int s = sqrt(v1) + v2 / v3 + fread(s). getChar(0)  //(?!?)
• List<int> getVal(int val, int len, String op) //(?!?)
2. Don't write uncorrect comments. Uncorrect explanations are worse than no-comment. 
3. Write comments for variables which are important and non-selfdocumenting.
4. Writing comments (e.g. JavaDoc declaration) for all public methods is a good practice. Of course, these comments should be "really necessary" and "as required".
5. Document "gotcha"s and "todo"s instantly when detected. These items may be remembered for that day but may not for tomorrow when not documented, so a buggy code will be inevitable.

Formatting

Formatting rules can be detected automatically by most tools (e.g. maven checkstyle) and applied automatically by most IDEs (e.g. Eclipse Code Formatter ctrl+shift+f). But there may be little differences between company formatting rules, so these tools should be configured before applying formatting.

1. Use brackets consistently. You may choose opening a bracket at the end of the current line or at the beginnning of the new line. Choose one of them and use consistently in the whole application.
2. Use blank lines consistently and as required. Blank lines may be used for separating  code lines or line groups semantically for readability. E.g. 3 blank lines at the end of a method, no-blanks on whole code or one or two blank lines between each line of code reduces readability and not good for eye pleasure.
3. Pay attention for indentation. Correct indentation for grouping statements is as important as using brackets and blank lines.
4. Character count of a line should be limited for readability. This limit is generally 80 for most developers, but may change a little due to some other development parameters. 
5. Using space chars in code should also be consistent in whole application. Generally, situations below are suitable for using spaces:
• Between operators and operands: 
• a += b , c = 0; (a == b)
• Between statement keywords and brackets: 
• if (value) {, public class A { 
• After ';' char in loops: 
• for (int i = 0; i < length; i++) 
• Between type casters and operands: 
• (int) value , (String) value

2 Implementations of "Chain of Responsibility" Pattern with Java

Chain of Responsibility design pattern is needed when a few processors should exist for performing an operation and a particular order should be defined for those processors. Also the changeability of the order of processors on runtime are important.

UML represantation of the pattern is as below:

Handler defines the general structure of processor objects. "HandleRequest" here is the abstract processor method. Handler also has a reference of its own type, which represents the next handler. For this a public "setNextHandler" method should be defined and exactly the handler is an abstract class. 

ConcreteHandler define different representations of processors. At last, Client is responsible with creating required handlers (processors) and define a chain order between them.

Generally two diffent implementation may exist for this pattern. Difference is related with the "location of the chain routing business logic". Chain routing business logic may be either in Handler abstract class or ConcreteHandler classes, or both of them. Sample of first two approaches will be given below:

1. "Handler" has chain routing business logic:

1. public abstract class Processor {
3.     protected Processor next;
4.     protected int threshold;
6.     public void setNextProcessor(Processor p) {
7.         next = p;
8.     }
10.     public void process(String data, int value) {
11.         if (value <= threshold) {
12.             process(data);
13.         }
14.         if (next != null) {
15.             next.message(data, threshold);
16.         }
17.     }
19.     abstract protected void processData(String data);
20. }
22. public class ProcessorA extends Processor {
23.    
24.     public ProcessorA (int threshold) {
25.         this.threshold = threshold;
26.     }
28.     protected void processData(String data) {
29.         System.out.println("Processing with A: " + data);
30.     }
31. }
33. public class ProcessorB extends Processor {
34.    
35.     public ProcessorB (int threshold) {
36.         this.threshold = threshold;
37.     }
39.     protected void writeMessage(String data) {
40.         System.err.println("Processing with B: " + data);
41.     }
42. }
44. public class Client {
45.     public static void main(String[] args) {
46.         Processor p, p1, p2;
47.         p1 = p = new ProcessorA(2);
48.         p2 = new ProcessorB(1);
49.         p1.setNextProcessor(p2);
51.         // Handled by ProcessorA
52.         p.process("data1", 2);
54.         // Handled by ProcessorA and ProcessorB
55.         p.process("data2", 1);
56.     }
57. }

2. "ConcreteHandler"s have chain routing business logic:

1. public abstract class Processor {
3.     protected Processor next;
4.     protected int threshold;
6.     public void setNextProcessor(Processor p) {
7.         next = p;
8.     }
10.     abstract protected void processData(String data);
11. }
13. public class ProcessorA extends Processor {
14.    
15.     public ProcessorA (int threshold) {
16.         this.threshold = threshold;
17.     }
19.     protected void processData(String data, int value) {
20.         System.out.println("Processing with A: " + data);
21.         if (value >= threshold && next != null) {
22.             next.processData(data, value);
23.         }
24.     }
25. }
27. public class ProcessorB extends Processor {
28.    
29.     public ProcessorB (int threshold) {
30.         this.threshold = threshold;
31.     }
33.     protected void processData(String data, int value) {
34.         System.out.println("Processing with B: " + data);
36.         if (value >= threshold && next != null) {
37.             next.processData(data, value);
38.         }
39.     }
40. }
42. public class Client {
43.     public static void main(String[] args) {
44.         Processor p, p1, p2;
45.         p1 = p = new ProcessorA(2);
46.         p2 = new ProcessorB(1);
47.         p1.setNextProcessor(p2);
49.         // Handled by ProcessorA
50.         p.processData("data1", 1);
52.         // Handled by ProcessorA and ProcessorB
53.         p.processData("data2", 2);
54.     }
55. }