Some worries about Class Oriented Programming

There have been a lot of posts from people lately concerned that what we have been calling “Object Oriented Programming” has, in fact, been implemented as “Class Oriented Programming”. In OOP languages, particular objects (instances) get almost all of their interesting properties from the class they belong to, which itself can derive much of its properties from the class it belongs to, all the way back to some basic Object class. We spend most of our time programming the methods and defaults for those classes.

The problem, which most people eventually run across, is that the world is not so neatly divided into such classes. In the real world, I am both a philosopher and a programmer; if for some reason you had both of these classes in your program (presumably inheriting from a Person class), which one should I belong to? It’s not uncommon to have just this problem in various web applications: you might have an Admin class and an Uploader class, but then sometimes you want someone to belong to both.

One (I think bad) solution to this issue is to try to have a multiple inheritance system, whereby an instance (or a class) can inherit from multiple classes. Personally, I think this would be messy quickly, although it is a step in the right direction. [One problem is that you would want to try to Classify everything, and so you would end up with an outrageous number of classes]

I think the tree system of classes is helpful, as far as it goes, but you should not try to make a class for every bundle of traits you can think of. Instead, reserve classes for times when you have proper subsets that are mutually exclusive. For example, BookCitations are a proper subset of Citations (there are non-book citations out there), and it is mutually exclusive of ArticleCitations (nothing can be both). So these, I think, are a good case for the current class system.

The Admin/Uploader division, however, is not mutually exclusive, so it is a bad use of classes. What we really want is to define various traits, and then give these traits to individual objects (or classes). One way you see this done is to create a boolean Admin column in the database, but I think this is bad practice. In Rails, I’ve seen some projects which deal with this through Roles, whatever exactly this means. In any case, people are seeing the problem when it comes to users, and I think we need to open this up to other classes/objects as well. We need to be building a Trait based system, not a class based one (except, again, where this is helpful).

I still have to think about exactly how to accomplish this, but it seems to me to be the right approach.