It's true that a class with a set of methods defines a contract with its collaborators about what calls they can make (or what messages they can send, in Smalltalk terms), that is a lot like a type. Smalltalk calls this a "protocol". But they aren't enforced by the compiler; you can still send a message to an object that it won't be able to understand. What happens in that case is that a method called doesNotUnderstand gets called; a class can implement that to try to do something useful (you could implement a proxy this way, for example), but the default implementation throws an exception. I think that a genuine type would prevent the message being sent in the first place - the could would be rejected by the compiler, and would never get a chance to run.
Interestingly, it seems that this was planned for Smalltalk, but never implemented; a 1981 article about the design of Smalltalk [1] says:
"Also, message protocols have not been formalized. The organization provides for protocols, but it is currently only a matter of style for protocols to be consistent from one class to another. This can be remedied easily by providing proper protocol objects that can be consistently shared. This will then allow formal typing of variables by protocol without losing the advantages of polymorphism."
