I have encountered a conundrum. I think I should know how to solve this — I even wrote a Python book — but I can't figure it out. It seems like what I am struggling with should be addressed by a design pattern that is a variation on the factory theme, but I can't recall one. (At the end of this writeup I suggest a technical solution, but it seems an implausible one.) I hope you find this discussion interesting in its own right, but I look forward to hearing some suggestions for solutions to my problem.
Given classes, A, B, C, and D, I want to limit creation of B instances to methods of A, C instances to methods of B, and D instances to methods of C — in other words A instances are the factories for B instances, B instances the factories for C instances, and C instances the factories for D instances. (I also want each instance of D to store which instance of C created it, each instance of C to store which instance of B created it, and each instance of B to store which instance of A created it, but this is easily arranged by having each instance provide itself as an __init__ argument when it creates an instance of the next class down in the hierarchy.)
These are model-layer classes that an application manipulates. There is no problem with the application manipulating instances of B, C, or D, it just shouldn't create them directly — all it should be able to create directly are instances of A (and A might even be a singleton). There are various kinds of validation, management, tracking, auditing, etc. that could be implemented in the methods of one class that create instances of the next.
An example might be a Computer that can create Filesystems that can create Directories that can create Files, but application code would have to follow that chain. For example, even if it had its hands on a Directory, it shouldn't be able to create a File giving File.__init__ the Directory instance even though that is what instances of Directory would do when asked to create a File. (In essence this is the underlying model of filesystems, though not the way it looks to application code or users.)
The only thing I have thought of so far is:
- begin all class name except A with an underscore
- access _B() only from A instances, _C() only from B instances, and _D() only from _C instances
- rely on application-layer programmers to respect this arrangement and directly create instances only of the (possibly singleton) class A
Module-level "hiding" by omitting the class from the module's __all__ list is insufficient, because the only affects import * constructions — another module could still reach the class by import module then referencing module.class.
(This is all vaguely reminiscent of the C++ problems that require two classes to be friends because they participate in a two-way relationship: instances of each class must be able to reference the methods of the other class that manage that the other side of the relationship.)
The solution the may best conform to the semantics and pragmatics of Python is to define D inside C, C defined inside B, and B defined inside A. This seems an awfully ugly way to cram multiple modules worth of code into a single very large class. (And imagine if the chain went down a few more levels.) This is an extension of more common uses of nested classes and maybe the only technically sound way of doing this, but I have never seen this sort of Russian-doll class structure.
Ideas?