Automatic (shared attributes-based) subclassing

In my design hierarchy I simulate a language whereby all objects have some type. It is the same as instances refer the class they belong to. The class (identically, a type) is nothing more than a set of properties (aka attributes or fields), common to all instances (aka objects) of the class. Now, there is a flyweight pattern which says that to save memory we must factor out the common invariants rather than copy them into every instance. For instance, you have a Boolean object, which refers class Boolean and bears a bit of information. However, all immutable instances that bear constant True in them, could just refer a subclass of Boolean, BooleanTrue and elimiate the need to bear the bit of information. The flyweight reference matches with the type reference. This coincidence motivated me to think that is is ok because classes are exactly the invariants, shared by instances. The BoolTrue could also simultaneouly represent a class and instance (multiinheritance) at the same time so that not even instances (and thus instance refs to the class) are necessary. You have only two instances: BoolFalse and BoolTrue! Whenever you need a boolean value, you just refer one of them.


Suppose you have an object that may be an
Object
  category: signal, variable, constant
  direction: none, intput, output, both

Theoretically, we have only 3x4 = 12 subclasses of object.  For the million of instances, I would like to allocate no more than 12 objects. If object has additional fields, e.g. location attribute (row:int, col:int), all input signals with the same location (say x0, y0) would be a subclass of InputSignalObject. Here, we must fix the field order (like in ROBDD) in order to prevent InputSignal and SignalInput appearing in our space and mistreat them as different classes (I think that only arrays of arrays are possible to program whereas conceptually we have a 2d array).

Secondly, because of combinatorial explosion, we can subclass only enumerations (creating a subclass for every point(x,y) might be an overkill) it might be good to create subclasses lazily, on-demand, when the instances are instantiated. The root class, redirects object construction, enumerates the enumeration-type fields and redirects the construction to the subclass to a subclass.

so that at each level a set of classes is created. Though, multiple levels can be combined if their fields always come together. For instance, OutputConstant can have concrete fields dir=Out and category=Const, since no path from Const to anything else exists. This might be especially true for classes with discrete range and reference fields because they do not split as enums.

There is a flyweight pattern but it does not consider the common base as a part of class.

I blur the line between class and its instances. As class comes down to only one instance, it represents the class. Suppose a million of boolean instances mapped to only two, True and False instances which are also classes. It should be a huge saver!

Is it a DB, OOP or Computer Science topic? I see that greatest lower bouńd of two objects can be tracked with (Featherweight) Typestates. The typestates are types, whose level of instance initialization can be tracked. But, I do not understand those articles very well.

This dream happens to be in on the track started by advise to save memory via polymorhpism-based parametrizing.