I have a simple domain with about 6 objects in the model. For the most part they have a clear child/parent relationship with parent having multuple children. I’m going to have all of them be immutable. However, at some point I’ll need to both fetch a set of all objects of a given type, and be able to fetch a specific object of a certain type by it’s label.
I was going to have a model with some generic maps, and an abstract class for objects in the model. Adding to the model sticks the object in my map, and asks for the parent objects and sticks those in the map etc. Likewise a delete can delete all classes that called themselves children. This way I can query for specific classes in a generic method without writing logic to hunt down each class.
Once I thought of this my next thought was rather I can use a similar framework to save CPU by looking up children in the same manner. If I already have to store “these objects claimed x was a parent” to do the delete I can then say “give me children of X”. However, this assumes that X knows something about the other objects (what classes are effectively children of it). I can put in type safty via reflection mostly; but is it brittle for one object to presume that certain other class is going to claim it as a parent and persumably be in the model as such?
TO clarify, lets say I have a node and edge class. My edge would report a node as it’s parent. My Node can then say “give me all Objects that claimed me as parent and are edges” and do logic on them; even though it never did anything to ensure that there were edges out there using it as a node. Is this wrong?
Note, this is a small system. I know that there are great abstraction patterns for huge systems, that I mostly don’t think are worth the implementation cost or less explicit code for such a simple system.
0
Like an interface, a non-final class is like a contract. Classes that derive from it are expected to satisfy the contract, regardless of what other features they support. Object-oriented languages do a lot to ensure that child classes do indeed satisfy the contracts specified by their base-classes, but in a few cases, the contract cannot be satisfied by the features of the language alone.
You should do what you can within your language of choice to ensure that the contract is satisfied (generics or templates might help here if they are supported). But I would say it’s okay to treat the child classes as though they satisfy the contract if you are not able to guarantee it through the language.
If its not a framework (with new children being added by users) and you put a smaller version of question in the parent as code comments then its fine.
Even if it was a framework it would be okay as long you have warned users, though would be more useful if there was some validation/ checking -> explicit and/or via language features.