Class for interpretation of capturing groups inside regex

I wrote a class, which intends to work with regular expression (as a String or Pattern object) to get capturing groups of given regex, but it operate on regex. I wrote it to implement in my regex app and it is working quite well. I wanted to make it simple to implement, reusable, and as much as possible easy to read and understand, to make it like public API. I would be grateful if someone would review it from point of view of:

• readability - is it easy to grasp what given method is for?

• reusability - is it easy to use/implement for others? Are there some obviuos flaws I don't know, etc.,

• maintaining - any visible bad practice for writing 'public' classes?

• hypothetical modification - is there something which could make implementing changes in class in future difficult for hypothetical user?

I aware that this is small class (but still sorry for long code), so I will be grateful for any comments on above topics, as also for any comments about code. I added main() method, so it is easy to compile and test, also it shows basic methods:

```
import java.util.*;
import java.util.regex.Matcher;
import java.util.regex.Pattern;

/**
* Tool for interpretation of the literal content of given regular expression. It performs analysis of capturing
* abilities of this regex
*/
public class Metamatcher {
private String pattern;
private TreeMap groupsIndices;
private HashMap namedGroupsIndex;

public Metamatcher(){
pattern = "";
namedGroupsIndex = new HashMap();
groupsIndices = (TreeMap)getGroups();
}

public Metamatcher(String pattern){
this.pattern = pattern;
namedGroupsIndex = new HashMap();
groupsIndices = (TreeMap)getGroups();
}

public Metamatcher(Pattern pattern){
this.pattern = pattern.toString();
namedGroupsIndex = new HashMap();
groupsIndices = (TreeMap)getGroups();
}

/**
* @param group ordinal number of group
* @return starting i

Before getting to your specific questions, let me just get a few nit-picky things out the way.

At the very beginning, in the imports, you have this:

import java.util.*;
import java.util.regex.Matcher;
import java.util.regex.Pattern;

but why not just have:

import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
import java.util.TreeMap;
import java.util.regex.Matcher;
import java.util.regex.Pattern;

Those are all of the dependencies in your program, and it's best to just write them out so everyone knows where each package is specifically. Many IDEs do this automatically now-a-days, so it's not hard to do.

Your class's name is Metamatcher. Again, this is kind of picky, but the naming of class would look a bit better to developers if it was MetaMatcher. The name itself doesn't really describe what's happening in the class either. This area is up to you, but perhaps something like RegCount or RegexUtil would be better, based on how much you plan to expand its functionality.

When writing the code out, please avoid the habit of something like this:

public void HelloWorld(){ ...

Just adding that extra space helps the visual appeal, and is kind of standard among JVM (and OOP) developers:

public void HelloWorld() { ...

Spacing can be good for some standard function calls in general as well, like with the for and while loops. I noticed that you didn't have this in a couple places.

When documenting your code, the standard for JavaDocs looks something like this:

/** Description of myMethod(int a, String b)
 * 
 * @param a         Description of a
 * @param b         Description of b
 * @return          Description of c
 */

When done this way, the description will actually appear alongside the function's parameters, which is a big help in IDEs like Eclipse.

Now, to actually attend to your questions:

Readability
For this one, most of my nit-picking should help clean up the code. As for what your code actually does, your documentation lists none of that. Yes, we get what the class is supposed to be used for and what the functions do, but apart from that we don't know what the code does solely from your documentation. If I were a newb, I wouldn't touch this. Instead, I'd most likely just scrounge through the Apache libraries to get what I need.

Reusability
Again, this is kind of answered by my nit-picking and previous answer about readability. At the end of the day, if developer's can't tell the purpose of the program through anything other than spending time to chug down the raw code, they probably won't want to take the time to bother. This is why documentation has been under a heavy magnifying glass recently, because even though we all hate it, it's kind of a necessary evil.

Maintaining
I'm not quite sure what you mean specifically, but just taking what your question after this title is, that I can answer. You seem to be just fine in terms of design, just always remember your nomenclature though. Also, instead of doing this excessively in your constructors:

namedGroupsIndex = new HashMap();
groupsIndices = (TreeMap)getGroups();

You can just put them directly at the variables, since you're only making a new instance of them:

private TreeMap groupsIndices = (TreeMap) getGroups();
private HashMap namedGroupsIndex = new HashMap();

Note the spacing :)

Go look at @Emz answer here, I'd highly recommend that.

Hypothetical Modification
When you say "hypothetical," you open the door to an endless world of opportunity. It all depends on what the program is designed to do. Only focus on what the program does, and how to do it better. If you have troubles on that specifically, then CR and SO will be of great help!

I went ahead and fixed your replaceWithSpaces function, as you can use String.format to do what you want:

/**
 * Provide a filler String composed of spaces, to replace part enclosed by
 * brackets
 * 
 * @param part
 *            String containing capturing group of regex, starting and
 *            ending with brackets,
 * @return String composed of spaces (' '), with length of part object,
 */
String replaceWithSpaces(String part) {
    return String.format("%1$" + part.length() + "s", part);
}

This pads the string up to part.length to the right. Since your string is empty, it doesn't matter which direction the pad is going.

Hope this helps!

StackExchange Code Review Q#100734, answer score: 4