Your abstractions are bad and you should feel bad

Introduction

There is no doubt about it. Every developer has at least encountered object oriented programming(OOP). The idea is quite simple. You have objects that you associate with a specific class(classification).

In most programming languages there is a simple notion of hierarchy in those classes. Also you can associate certain methods to such objects. Easy.

Some see those methods as messages that are sent between these objects. A program becomes a vast web of messages sent (chaotically)dynamically. Rather than having one monolith of muddy code with loads of opportunity to duplicate yourself we now have 3500 small method calls that are small and simple to read(if you were to actually follow that web).

It also allows for abstraction. Rather than solving the same problem 20 times, create one abstract program and all will be well.

Those are a good points OOP enthousiasts make. Here however are a few limitations that I have encountered with the way we do things today.

Your abstractions are bad and you should feel bad

Yup, everyone I’ve ever met, including myself, sucks at abstraction. And there is a good reason.

Defining a class isn’t easy at all.

A simple example. A car or automobile is a wheeled, self-powered motor vehicle used for transportation.

So if I use it for other uses than transportation it no longer is a car?  Also my motorbike isn’t a car. Did you think a car has 4 wheels? Nope.

I’m nitpicking right? Think about what would happen if an automated machine were to handle cars and assumed it has 4 wheels. The same will happen with your abstract method. But you can fix that. It’s still good.

Another common problem I’ve seen is that there is no name for that abstract thing we’re building. Simply because it’s a new abstraction that was never done before. Or a more common problem: the abstraction describes multiple things. Our language (or maybe my language skills) isn’t elaborate enough. Everyone hates the CarsWithFourWheelNotABikeThough class.

Methods on classes

Putting methods on classes make sense. Such as toString() in java or some function that would only apply to that specific object like Person.isBelgian(). These kind of functions always receive my seal of approval.

But step back for a second. It gets very clumsy if you have multiple input types for one method. On which class are you going to put that method? Here is a silly example:

Egg.CrackOnPan()

Or is it Pan.CrackEgg()?

I have had this discussion way too many times. Especially if the amount of input types goes over 3. These are not fun and productive discussions. It turns out we just exhaust each other and let fate decide. Later on you never find that method you were looking for.

Entities usually have more than one class

A class indicates that an entity agrees to a specific classification. That’s right a classification. In most programming languages we tell the compiler that an object belongs to one specific class. Some languages allow multiple inheritance but still it implies some hierarchical structure.

The idea is, it belongs to a specific class because the programmer tells you so.

My dog is a mammal. Easy to express in any OOP language. He has also won a price. So I classify him as a price winner. But hey, he can also swim like an otter. My point? An object/entity seldom belongs to one class. We as humans classify entities all the time. Converting an object between classes is much work(especially when done dynamically). This is mainly because of the tight coupling between what methods that can be called upon that object and what class it belongs to. This is a design decision on the language part. Sure there are tricks to solve this (including hierarchy) but the fact that it takes skill and experience to do this properly tells me there is something wrong.

Conclusion

I feel there is a great opportunity out there to create a programming language that can express classifications more dynamically and make the coupling between methods and classes loose. (I’m not talking about duck typing) A method sometimes isn’t a one-on-one to a class but is applied to multiple classes at the same time. This cannot easily be expressed in current languages.

Also while you’re at it, a language that allows reflection on the instruction level would be great, I’ll tell why in my next blog 🙂