> OOP - in practice - does tend to encourage far too many types. Keep in mind that the concept of a class unifies the concepts of modules and types. A class ca

> OOP - in practice - does tend to encourage far too many types. Keep in mind that the concept of a class unifies the concepts of modules and types. A class can be seen both as a module (with late binding, and of which there can be several instances) and as a record (with methods to abstract over the representation and allow polymorphism). The advantage is that you don't need a second module language on top of the type system. Consider, for example, that as of OCaml 4 - with first-class modules and generative functors –, OCaml's module language is essentially a second fully-featured OO system. Using it as such would be awkward because of all the boilerplate involved (it isn't meant to be used that way), but all the functionality is there. This is basically because first-class modules provide late binding and generative functors allow for multiple instances of the same module. But this means that, yes, you get more types because some of these types are actually modules in disguise. > The solution I always try to keep in mind is that OOP can be useful if-and-only-if the data actually has a hierarchy. A single standalone class is equivalent to a basic struct passed to functions. Not really. A basic struct does not have methods that abstract over the representation and does not support polymorphism. Also, it avoids duplicating language functionality for concepts with overlapping, but not identical functionality. Note also that structural subtyping does not require a hierarchy.