Liskov Substitution Principle

Notice that the add(), get(), remove(), and getIterator() methods do nothing but throw UnsupportedOperationException. This is because these operations are not available in the leaf objects in the composite hierarchy such as ChemicalSample. They only make sense in the composite objects such as ChemicalLibrary. Defining these methods in the component class makes the design compliant with The Liskov Substitution Principle (Martin, 2003). 

The Liskov Substitution Principle Subtype must be substitutable for the base types. 

An approach currently being examined in the context of DO-178C is to require the members of a type hierarchy to obey the Liskov Substitution Principle (Liskov and Wing 2001). This is a formalization, in terms of preconditions and postconditions, of the principle that the behaviour of a derived member should be similar in a formal sense to its parent s behaviour, so if the Draw call works for one, it is guaranteed to work for all. 

---

See also in sourсe #XX -- [ , , ]

---