What are the tradeoffs between a Union type or a wrapper Class to represent a formatted string argument representing multiple types

Question

Assume there's a public void process method on a Java class called A that currently takes a single String argument id.

class A {
  public void process(final String id) {
    // Some implementation
  }
}

The existing method's String id argument has a specific format: type#integer where type can be foo or bar (so foo#1 and bar#1).

While the underlying implementation does not change based on the format of id, having the method take a String seems less accurate than representing the argument as a concrete type, especially when unfamiliar readers examine the public interface of the class.

One approach is to parse the id value into one of two classes (FooId and a BarId) and to represent the id argument as the Union of two input types - a FooId and a BarId.

public class FooId {
}

public class BarId{
}

public class IdParser {
  public Union<FooId, BarId> parse(final String id) {
    final String parts = id.split("#");
    if (2 == parts.length) {
      final int value = Integer.parseInt(parts[1]);
      if ("foo".equals(parts[0])) {
        return Union._1(new FooId(value));
      }

      if ("bar".equals(parts[0])) {
        return Union._2(new BarId(value));
      }
      
    }
    throw new IlllegalArgumentException("Invalid id value");
  }
}

public void process(final Union2<FooId, BarId> id)

Another approach is to represent the id value as a "generic" Id class that wraps the two types and keeps track of the type based on an internal Type enum like

class Id {
  private static final enum Type {
    Foo,
    Bar;
  }

  private final Type type;
  private final int value;

  private Id(final Type type, final int value) {
    this.type = type;
    this.value = value;
  }

  public static Id from(final String formattedId) {
    // parse the type and value and return an Id instance
  }
}

What are the tradeoffs between these two approaches?

Would you instead recommend using method overloading instead of a Union?

public void process(final FooId id)
public void process(final BarId id)

Answer 1

Ignoring some of these implementation details, the advantage of the second approach is the ease with which a BazId can be added.

Of course none of that matters unless Id's being different types actually means something. If you scatter around a lot of type testing code you're right back to adding BazId being difficult.

By which, I mean, these types need code that uses them to be useful. Be it polymorphic code or if type==bazId code. Without that the types are pointless. This is missing from the examples in the question. If such code must know all the types and appears in many places all those places must be changed to add a new type.

That concern drives you back to the first approach. Some even do it with a big switch statement.

Ideally you could simply add one new file and poof BazId works. The closest I've seen anything come to that is a class loader. But, well now you've simply moved the code that knows all the types to a configuration file.

The fundamental problem is something must create an ordering for these types to give them their numbers. And that something can't be allowed to renumber old ones with new numbers or old strings become invalid.

So what we're left with is each Id class must declare it's own number. And carefully avoid using any other Id types number.

Do that and when adding new types you can avoid forcing rewrites of old code. Without that, either way ends up just as messy in the end.

This is not a new problem. It's the serialVersionUID part of Java Serialization all over again.

Answer 2

If you want separate Types for Foo and Bar the union approach is flawed. After you parse the string you need to check for null to see what if any Type was parsed. As you add more types you will have to extend to a UnionN<foo,bar,baz,whatever....>

The correct approach would be to use polymorphism

Interface Id
{
    string StringRepesentation
    void ParseString(string id)
    object RealId
    void Process()
}

class FooId : Id
{
    bool ParseString(string id)
    {
       If(id.StartsWith("foo") { this.RealId = //parse out the int ..
       else { return false;
    }
    void Process() {}...
}

class IdParser
{
     public Id Parse(string id)
     {
        //loop through known types and return the one that matches
     }
}

//now you can call the correct processing logic
var Id = IdParser.Parse(string);
Id.Process()

But overloading is ugly and the parsing at least in your example is pretty meaningless.

You could use a Union if all your Ids have the same pattern

Union<string, int> id
id.first = string.split("#")[0];
id.last = string.split("#")[1];

if(id.first = foo) { ..process foo

But you will need all the extra parsing and re serialising logic somewhere. The generic id class is a better approach because it can hold that logic.

However. You don't really give a good reason to convert the string at all. However you do things you are going to have some sort of switch, if block or loop to sort out the types. overloading and polymorphism are not really in good favour these days, its seen as complex and cumbersome compared to simple composition.

If your Ids are a simple combined key with two parts just keeping them as strings and testing for startsWith() when you load whatever object they refer to, which presumably will benefit from a Type, is the simplest approach.