0

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?

4

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.

  • Sounds like my instructor, really. There's a lot of "but do I really need this code" that he talks about. – Addison Crump May 20 '17 at 21:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.