When you say that your code snippet looks similar to the “Solution 1″ code and therefor violates the OCP, I’d say it’s actually more similar to the “Solution 2″ code which doesn’t violate the OCP. This is because when you make a new flightless bird class, you don’t have to modify the ArrangeBirdInPattern function. In “Solution 1″, you have to modify the function every time a new flightless bird class is created.

Like most software development advice, the LSP is just a rule of thumb. You can think of an LSP violation as a kind of code smell. It indicates that there may be a better way to structure the code.

As for the Java exceptions, I had a quick google (doesn’t that sound dirty) and found this:

class: java.nio.ByteBuffer
method: public ByteBuffer put(ByteBuffer src)
throws: ReadOnlyBufferException (extends UnsupportedOperationException) – If this buffer is read-only

If you have a subclass of ByteBuffer that is read-only, I would say that it does violate the LSP. If you can never call “put”, then it shouldn’t have a “put” method at all. You could get around this by having two interfaces like ReadableByteBuffer and WritableByteBuffer. Then you can choose not to implement WritableByteBuffer if the class is read-only.

When you say that your code snippet looks similar to the “Solution 1″ code and therefor violates the OCP, I’d say it’s actually more similar to the “Solution 2″ code which doesn’t violate the OCP. This is because when you make a new flightless bird class, you don’t have to modify the ArrangeBirdInPattern function. In “Solution 1″, you have to modify the function every time a new flightless bird class is created.

Like most software development advice, the LSP is just a rule of thumb. You can think of an LSP violation as a kind of code smell. It indicates that there may be a better way to structure the code.

As for the Java exceptions, I had a quick google (doesn’t that sound dirty) and found this:

class: java.nio.ByteBuffer
method: public ByteBuffer put(ByteBuffer src)
throws: ReadOnlyBufferException (extends UnsupportedOperationException) – If this buffer is read-only

If you have a subclass of ByteBuffer that is read-only, I would say that it does violate the LSP. If you can never call “put”, then it shouldn’t have a “put” method at all. You could get around this by having two interfaces like ReadableByteBuffer and WritableByteBuffer. Then you can choose not to implement WritableByteBuffer if the class is read-only.

from a software architecture point of view I can fully agree to you. Subclassing the Bird for the FlightfulBird does make sense to group the flying ones alltogether. It is a reasonable choice both from a software design point of view and the semantically perspective.

But in practice the downsides stay exactly the same. To implement an apropriate ArrangeBirdInPattern-method you need to approximately do the following:

void ArrangeBirdInPattern(Bird* aBird)
{
FlightfulBird * aFlyingOne= dynamic_cast(aBird);
if(aFlyingOne)
ArrangeBirdInSky(aFlyingOne);
else
ArrangeBirdOnGround(aBird);

}

That looks pretty similar to the “blatant violation of the Open Closed Principle” earlier in this article. The difference is the use of an (abstract) superclass or interface instead of a single concrete subclass of Bird.

Did I get something wrong or is the LSP rather an academic subtleness and a design faux pas that a practical problem?

Besides in the Java Collection Framework the use of UnsupportedOperationException is pretty common (Collections.unmodifiableList()). The interface List itself even declares that such an Exception may be throws. Is this a violation of LSP?

Best regards
Andy