Fulfilling the Semantic Contract

• Guideline: Make sure subtypes fulfill the semantic contract of their supertypes.
• An OverdraftAccount IS-AN Account means: I can use an OverdraftAccount where an Account is called for.
• Compiler will complain if the OverdraftAccount's interface isn't compatible with Account's.
• But the compiler won't say a word if OverdraftAccount's violates Account's semantic contract.

Why Fulfill the Semantic Contract?

• If an OverdraftAccount violates the semantic contract of Account, you can't be sure you can use an OverdraftAccount where an Account is needed.
• Put another way: If OverdraftAccount violates the semantic contract of Account,
  

  OverdraftAccount IS-NOT-AN Account.

• If you don't, you can't take advantage of polymorphism and dynamic binding
• If you don't, you muddle the meaning of inheritance

• CloneNotSupportedException

That's big fence country up there.

The subfence must be completely enclosed by the superfence. Refer to Collection, Set example from interface extension guideline.

Use Venn diagrams to show the problem of mismatched concepts of semantics by various programmer parties (API designs, clients, service providers) Show a Venn oval with three points in it, p1, p2, p3. Say those points could represent different implementations by 3 different vendors, or 3 subsequent implementations by the same vendor. None of those implementation points will break client code so long as all clients and all service providers have appropriate expectations. As Robert Frost said, "Good fences make good neighbors."