Question

For example, I have a class that has two strings, one of which must be set, the other of which could be null:

public class SomeClass{
    private String s1;
    private String s2;

    ...
}

I could define a constructor as follows:

public SomeClass(String s1, String s2){
    if(s1 == null && s2 == null) throw new SomeKindOfException("can't both be null");

    this.s1 = s1;
    this.s2 = s2;
}

I would rather do something along the lines of:

public SomeClass(String s1){
    this.s1 = s1;
}

public SomeClass(String s2){
    this.s2 = s2;
}

Which obviously can’t work because it defines two methods that take the same number and type of parameters.

So, I would like to do something like:

public SomeClass(SomeTypeOfString s1){
    this.s1 = s1;
}

public SomeClass(AnotherTypeOfString s2){
    this.s2 = s2;
}

This has the added advantage that the “types” of String could validate their contents (e.g. SomeTypeOfString must be 6 chars long and AnotherTypeOfString must be between 4 and 8 chars long and only contain alpha-numeric chars.

Also, it makes it clearer, when calling a function, what data should be passed in.

So firstly, does this concept sound sensible?

In terms of implementation, you cannot extend String. You could wrap it though. The “types” of String are essentially types of String, so it would make sense to have them extend an abstract wrapper class. This could be implemented as follows:

public abstract class StringWrapper{
    private final String string;

    public StringWrapper(String string){
        this.string = string;
    }

    public String getString(){
        return string;
    }
}

public class SomeTypeOfString extends StringWrapper{
    public SomeTypeOfString(String string){
        super(string);
    }
}

The code for the SomeTypeOfString class looks rather silly, as all it does is define a constructor that calls the super-class’s constructor… But assuming you also add some validation in there, it looks sensible to me. Does this implementation sound sensible?

Can anyone think of a better concept to solve the basic problem, or a better implementation for the concept I outlined?

Answer 1

Your concept and implementation do look sensible and can even improve readability if used consistently.

For example if one “type” of string represents a product id, then you can produce this class:

public abstract class ProductID{
    private final String id;

    public StringWrapper(String id){
        Preconditions.checkNotNull(id, "Can't construct a ProductID from null");
        Preconditions.checkArgument(isValidId(id), "%s is not a valid Product ID", id);
        this.id = id;
    }

    public String getID(){
        return id;
    }

    public static boolean isValidID(id) {
      // check format
    }

    public boolean equals(Object o) {
        return (o instanceof ProductID && ((ProductID) o).id.equals(this.id));
    }

    public boolean hashCode() {
        return id.hashCode();
    }

    public String toString() {
        return id;
    }
}

Note that equals()/hashCode() is necessary to be able to use ProductID as a key in a Map or to ensure uniqueness in a Set and similar things (apart from being generally useful). toString() can either be useful as a debug tool (in which case I’d add the class name, maybe using the neat MoreObjects.toStringHelper() approach or manually) or for rendering the product id in a way that is used on the UI (in which case the given implementation might be fine).

This has several advantages:

• you know that every ProductID object holds a valid product id (at least syntactically)
• methods that takes a ProductID make it very explicit what that value holds. If they accept a String instead it’s not so clear.
• You can easily distinguish between two methods that take some IDs just from their argument type.

Unfortunately I can’t say that I have experience with such a system in any large-scale systems (I used it plenty in smaller systems). But some disadvantages that I’ve seen and/or can imagine are this:

• external APIs: If some code calls you, it can usually handle String, but not ProductID, so you’ll need to convert
• there will be places where you still need to use bare String values: when the user enters a value, you might need to be able to store it, even if it’s not a valid product id.
• mindshare: developers need to buy into this concept, really grasp it and embrace it. Otherwise you end up with an ugly mix of String/ProductID with tons of conversion everywhere.

From these three, I think the last one is the most severe.

If, however, this seems like overkill to you, then using factory methods instead of constructors could be a solution:

public class SomeClass{
    private String s1;
    private String s2;

    private SomeClass(String s1, String s2) {
      Preconditions.checkArguments(s1 != null || s2 != null, "One of s1 or s2 must be non-null!");
      this.s1 = s1;
      this.s2 = s2;
    }

    public static SomeClass fromSomeString(String s1) {
      return new SomeClass(s1, null);
    }

    public static SomeClass fromAnotherString(String s2) {
      return new SomeClass(null, s2);
    }

    public static SomeClass fromStrings(String s1, String s2) {
      return new SomeClass(s1, s2);
    }
}

Note that I use the Guava Preconditions class to shorten the argument checking code.