The interactions with a few known other classes just help illustrate how the methods are used. The real contract you must not break is the Liskov Substitution rule, that ANY class that works with the original must work with your class. If we had a full set of
unit tests for the original, this would be a lot easier, but we don't, unless you want to make some
What kind of extensions do you have in mind? If it's only new methods you are probably pretty safe. If it's overriding some methods to gives different answers, you may be in big trouble.
A textbook example of potential trouble: In geometry, a square IS a rectangle. So in a drawing program you might be tempted to make Square a sublcass of Rectangle. The new rule for square is the sides are all the same length, so override setWidth() to also set height, and setHeight to also set Width. Is life good? According to Liskov,
you should be able to pass a Square to the unit tests for Rectangle. How about:
And what do you do with the constructor new Rectangle( width, height )? Sometimes extending is just not the right answer.