Identifying the use case for instantiation only through existing instances

Question

I was in my CS class when my instructor presented me the following classes:

public class UninstantiableTest {

    private static Uninstantiable uninstantiable;

    public static void setUninstantiable(Uninstantiable used) {
        uninstantiable = used;
    }

    public static void main(String[] args) {
        Uninstantiable.setupUninsntatiableTest();
        Uninstantiable test = uninstantiable;
        for (int i = 0; i <= 100; i++) {
            test = test.new InstantiableWithOther(Integer.toString(i));
            System.out.println(test);
        }
    }

}

public class Uninstantiable {

    public static void setupUninsntatiableTest() {
        UninstantiableTest.setUninstantiable(new Uninstantiable());
    }

    private Uninstantiable() {}

    public class InstantiableWithOther extends Uninstantiable {

        private String string;

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

        public String toString() {
            return string;
        }

    }

}

I was then asked for a likely use case for a class setup like this, to which I replied "For applications which you wish to grant privileges to selectively by passing objects", but he didn't seem pleased with this answer.

What are the use cases (if any legitimate use cases exist) for allowing instantiation only through an existing instance of the same type?

Answer 1

What this pattern is doing is using access modifiers on constructors to limit construction to factory methods that have a hard coupling to other classes that are using setter injection. Why it's doing that is really anyone's guess but it offers control over construction at the expense of coupling. Similar tricks are used by the singleton pattern.

Like the singleton pattern this pattern very much feels like it was born out of paranoia. The control over construction being gained here is far outweighed by the coupling caused. I mean, come on. Unsustainable has to KNOW about it's test? That's just soooo wrong.

I think the only practical use this code has is to show people that just because something is amazingly tricky doesn't mean it's good. Maybe that's what your instructor wanted you to see.

I was once boxed into a corner writing something very much like this. In the end I couldn't stand the coupling and opened up the constructor to the package level so at least my factory methods didn't have to all live in the same class.