Object-oriented – What’s the difference between a subclass and a subtype

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.

To overload a method with a new method, the new method should have a different signature. I.e. two overloaded methods have the same name, but different parameters. Here's an example of two overloaded methods:

boolean isOdd(int number) { ... };
boolean isOdd(float number) { ... };

Based on the parameter types, the corresponding method will be called. Note that changing the return type is not enough (though you can do this additionally).

When a method is overridden, then the new method has the same signature and replaces the overridden method in some cases. Here's an example of an overridden method:

public class A 
{
     public void someMethod() { ... }
}

public class B extends A
{
     public void someMethod() { ... }
}

The choice is made based on the object type. For example,

A someA = new B();
someA.someMethod();

will call the someMethod of B. You can (and should) add the @Override annotation:

public class B extends A
{
     @Override
     public void someMethod() { ... }
}

Now, if you accidentally change the parameters in B, the compiler will inform you, that you are not overriding someMethod() but overloading it.