> The object-oriented tradition obsesses with encoding is a relations among types as a class hierarchy. That's a fallacy. Complicated type hierarchies are a mi

> The object-oriented tradition obsesses with encoding is a relations among types as a class hierarchy. That's a fallacy. Complicated type hierarchies are a mistake in object oriented programming. There are a lot of good reasons to use inheritance, but it's not really something that should be obsessed about. A large "object oriented" program will still declare the large majority of its types without inheritance. (Or with minimal inheritance, SomethingService inherits from ServiceBase, SomethingRecord inherits from RecordBase.) > When I use a tool and get unsatisfactory results, I blame myself for not using the tool correctly. > The approach of piling classes on top of one another and trying to make this stack coherent is fundamentally flawed. It fails spectacularly even on tiny examples where the problem domain is mathematically specified. Yes, you aren't using the tool correctly. You can not interchange rational and natural numbers in a computer without conversion. Typically rational and natural "classes" wouldn't share a common base class, but might share common-ish interfaces. For example, in C# I could declare a generic INumber interface, and all my number types could support it, but by the nature of being generic, you can't interchange a rational and natural without performing some kind of conversion. (INumber<TNumber> where TNumber : INumber) This would allow a programmer to write generic code that handles an INumber, but not a mix of different INumber types. (SomeMethod<TNumber>(TNumber arg) where TNumber : INumber<TNumber>) (I believe newer C# has something like this baked-in, but I haven't used it yet.)