Each module should be concerned with only its own actual needs – not its implementation at the then-present time. If A needs the functionality of B, B1, and B2, then "superficially" you should include all three ... while, perhaps, "idly wondering why this is so." What, exactly, is it about the present concept of "module A" that makes it simultaneously need not only knowledge of two subclasses, but also ("class-busting ...") knowledge of the parent class from which both of the other two were derived? "This smells bad..."