Object-Oriented Coding Standards – Should Equality Be Commutative Within a Class Hierarchy?

Jon Lin's got the solution you want. (+1 to Jon) An anonymous class is the way to go. Otherwise: if you want to use the same class more than once, a named local class can be used, just as you have it in your question. If you need it in more than one method, switch to a private inner class. If it helps other classes work with the parent class, then use a public inner class. If it's not tightly tied to its parent, put it in its own file.

The basic idea is encapsulation of the class (as opposed to data--a variable or field). The class itself should be known only to the code that needs to know about it. If you make it a nested class, someone looking at the reference has to go look for the class code and someone looking at the nested class code has to go looking for a reference. With a good IDE this is not too hard, but with local/anonymous classes its easy even when looking at the code in Notepad. And then there's the problem of getting data to and from the class....

Java is really good with this. Some other languages don't allow local classes. To be fair, they don't require them, either--a lot of standard Java classes are written with the idea the user can easily generate swarms of local, temporary classes. But, as in your case, local classes are quite handy even without the system classes that want them.

Here's the actual principle:

Let q(x) be a property provable about objects x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T.

And the excellent wikipedia summary:

It states that, in a computer program, if S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e., objects of type S may be substituted for objects of type T) without altering any of the desirable properties of that program (correctness, task performed, etc.).

And some relevant quotes from the paper:

What is needed is a stronger requirement that constrains the behavior of sub-types: properties that can be proved using the specification of an object’s presumed type should hold even though the object is actually a member of a subtype of that type...

A type specification includes the following information:
- The type’s name;
- A description of the type's value space;
- For each of the type's methods:
--- Its name;
--- Its signature (including signaled exceptions);
--- Its behavior in terms of pre-conditions and post-conditions.

So on to the question:

Do I understand correctly that Liskov Substitution Principle cannot be observed in languages where objects can inspect themselves, like what is usual in duck typed languages?

No.

A.class returns a class.
B.class returns a class.

Since you can make the same call on the more specific type and get a compatible result, LSP holds. The issue is that with dynamic languages, you can still call things on the result expecting them to be there.

But let's consider a statically, structural (duck) typed language. In this case, A.class would return a type with a constraint that it must be A or a subtype of A. This provides the static guarantee that any subtype of A must provide a method T.class whose result is a type that satisfies that constraint.

This provides a stronger assertion that LSP holds in languages that support duck typing, and that any violation of LSP in something like Ruby occurs more due to normal dynamic misuse than a language design incompatibility.