Switch Cases vs. If, else when comparing multiple strings

You should not code this way, DRY is the most important rule in coding--and when you look at your switch statement you will find a LOT of redundancy. The reason you are not supposed to use if/elseif chains like this also applies to switch statements--they are a bad code smell simply because they lead to redundant code.

So the first thing to do is look at what's different in each block. Here is your redundant code:

if(line.contains("SomeDataIKnow"){
    data = new Scanner(line).useDelimiter("=");//scans just the one line
    value = data.next();//sets value to the string right after the =
    this.Data1 = value;
}
else if(line.contains("DifferentDataIKnow"){
    data = new Scanner(line).useDelimiter("=");
    value = data.next();
    this.Data2 = value;
}

The differences are [SomeDataIKnow, Data1] vs [DifferentDataIKnow, Data2]

Scalars are not a good way to store data like this--they often make you create code like yours above because there is no obvious easier way, so generally I use a map.

So if I saw this code in my codebase my first refactor would look something like:

String[] strings=new String[]{"SomeDataIKnow","DifferentDataIKnow"};
Map results=new HashMap<String, String>()

for(String sub:strings)
{
    if(line.contains(sub){
        data = new Scanner(line).useDelimiter("=");
        value = data.next();
        results.put(sub, value);
}

This has some issues but works. You don't have to add any code when there are new strings to check for, your code is reduced by 30x and any patch to your if statement/code doesn't need to be repeated in 30 different locations.

The biggest issue is that it's no longer trivial to look up the value. You need the key which is the string "SomeDataIKnow", pain in the butt... You used to have a variable "Data1".

If you want to retain "Data1" you can make your string something like:

String[] strings=new String[]{"SomeDataIKnow:Data1","DifferentDataIKnow:Data2"};

and then do a String[] split=sub.split(":") and do the lookup by split[0] but enter it into the map by split[1]

After this instead of using this.Data1, you'd use results.get("Data1") which is reasonable.

There are LOTS of other ways to supply metadata for a common operation like this.. as long as you keep it DRY, most will work fine. I use the string array construct only because it's easy to initialize and work with... same for split.

As an example of another approach, if you really wanted to use scalars you could set your class up like this:

class MyClass{
    @SearchStr("SomeDataIKnow")
    String Data1;
    @SearchStr("DifferentDataIKnow")
    String Data2;
...

Annotations are pretty easy to process these days--you would simply go through all @SearchStr annotations in the class to build your search terms, loop over them the same way as above and stuff the resulting values into the corresponding variable.

The trick of refactoring patterns like this is simply to identify differences and group them--any way that makes you feel comfortable and doesn't add too much complexity.

By the way, once you have the results in a map look at where they are used. You will often find other redundant code there that can be refactored out--refactorings like this can chain to make huge savings across your codebase.

One possibility could be to use a Map. As you scan each line, add an entry to the map where the key is the part you know before the '=' and the value is the part after the '='

Then, after the loop, you could write something like:

this.Data1 = map.get("SomeDataIKnow");
this.Data2 = map.get("DifferentDataIKnow");

etc.

You might want to consider using a Regex Pattern. If the files are not too large, you could read the entire file into memory, then use a carefully crafted Regex Pattern to search for (SomeDataIKnow|DifferentDataIKnow|...)= and capture both the matching text before the equals sign and everything between the = and the next line break.

The main effect this would have is to allow your program to scan through the file's contents just once instead of 40 times. If searching through the contents is what's causing things to go slowly, then that should help.

Once you know the exact pattern that got matched before the equals sign, then you have a specific string that you can use in a switch statement or look up in a HashMap<> or any of the other approaches suggested by Bill K.