Quick update from the field.
So, Sonar said I needed to override equals and hashcode on this subclass, so I did, but now I’m having trouble with the code coverage, and the equals and hashcode tester doesn’t like my subclass.
My dear friend and colleague showed me the code and I noticed right away the fact that his new lookup table logic was a subclass of a
Map type. It’s no surprise that the tools started to demand that he provide the usual subclasses and test coverage for this.
But here’s the thing. His code, though lookup tabley, wasn’t REALLY a full implementation of the map, nor did it genuinely behave as per the interface. It was able to use the parent class to achieve its mission, but it was, essentially an imposter!
This is where Liskov Substitution is a good litmus test of whether a subclass is appropriate, and it’s an example of a good saying.
You’d really better BE something in order to be a subclass of it.
If in doubt, use composition.
That said – ModelAssert uses a TON of multiple inheritance in Java… which surely shouldn’t work… but appears to!