Kevlin HenneyWhat named principles (e.g., information hiding, DRY, etc.) in software development do you find are often referred to but are commonly misunderstood (or are actually flawed)? I have a talk, Principle Misunderstandings, where I cover a few, but I'm planning to extend this to half- and full-day formats, so I'd be interested in what you find is commonly misunderstood.
Stuart Marks@kevlin Liskov Substitution Principle (LSP). People think it means a subtype can’t reject a message by throwing an exception, when permitted by specification, like Java’s unmodifiable collections. In fact Liskov’s original paper has an example of a subtype throwing an exception in response to a message it doesn’t support.
@stuartmarks Could you clarify where she says this? This is not my understanding of the original paper.
@kevlin OK. Vacationing now. Will follow up with citations and quotes in a couple days when I’m back at my desk.
@kevlin The citation is to the Liskov paper that everybody cites, which I believe is the first one that talks about hierarchy and inheritance:
Liskov, Barbara. Data Abstraction and Hierarchy. ACM SIGPLAN Notices V23N5, October 1987, Addendum to the OOPSLA 1987 Proceedings. https://dl.acm.org/doi/10.1145/62139.62141
For convenience, the oft-quoted section that introduces the notion of substitution is the first paragraph of 3.3, “Type Hierarchy”: (1/6)
«A type hierarchy is composed of subtypes and supertypes. The intuitive idea of a subtype is one whose objects provide all the behavior of objects of another type (the supertype) plus something extra. (2/6)
@kevlin
@kevlin
«What is wanted here is something like the following substitution property [6]: If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2, then S is a subtype of T.» (3/6)
@kevlin
@kevlin
The next couple paragraphs cover examples of types that are not subtypes of each other, such as lists and sets or stacks and queues. The paper continues with a couple examples of subtype hierarchies, the first being indexed collections, followed by this: (4/6)
@kevlin
@kevlin
«The second example is abstract devices, which unify a number of different kinds of input and output devices. Particular devices might provide extra operations. […] Another possibility is that abstract devices would have all possible operations, e.g., both ‘put_char’ and ‘get_char’, and thus all subtypes would have the same set of operations. (5/6)
@kevlin
@kevlin
«In this case, operations that not all real devices can do must be specified in a general way that allows exceptions to be signalled. For example, ‘get_char’ would signal an exception when called on a printer.»
A printer throwing an exception in response to ‘get_char’ is similar to a Java unmodifiable collection throwing an exception in response to a mutation method. (6/6)
@kevlin
@stuartmarks Ah, OK, I was familiar with this section and conclusion, but I realise now I misread your original post.
I had assumed that you were saying exceptions were unconditionally OK, whereas I now see you carefully stated — and I overlooked — "... when permitted by specification", which naturally leads to covariant exception substitution.
In which case, yes, we are definitely agreed on this interpretation! Thanks for taking the time.