What do functional programmers think of the class inheritance hierarchy?

When a functional programmers looks at the typical OOP examples that show the inheritance hierarchy, they see something weird: why is one possible field plucked out to become the class? And why make it static?

Transcript

Eric Normand: How does a functional programmer see the class inheritance hierarchy?

Hi, my name is Eric Normand and these are my thoughts on functional programming. In a language like Java that has...it's object-oriented, has a class hierarchy where the class is also used in its type system to represent different types.

You have this thing that often happens, which is that people will model their domain using the class hierarchy. The class hierarchy represents is-a relationships. Class members, instance members, variables in the object represent has-a relationships.

You can get pretty far with is-a and has-a, I'm not saying anything about that. A functional programmer typically has a different perspective on this. I'll share my perspective on what's going on there and why we don't like doing that so much.

Imagine you have a spreadsheet. You work at a dog training company. You take care of dogs, you train them. You have all these customers in a spreadsheet. There's a bunch of dogs. You have something like the name of the dog, the time they first came into your service, their age, their weight, their height, their color, their fur color.

Then you have something like the breed of the dog, because that's important for training dogs. This spreadsheet is really useful. You can sort it in different ways. You can figure out what's the average amount of time it takes for a big dog to be trained versus a small dog.

There's all sorts of questions you can ask this data. Because it's in a spreadsheet and it's very loosely structured, it's just a rose in a table. It could be in a sequel database, it doesn't matter, as long as all that data is still there. You can make pivot tables. You can do all that stuff you normally do with a spreadsheet.

What does an object-oriented person do? The first thing they do is they look through those columns, and they say, "Wait a second, this breed of dog, the type of dog it is, is an is-a relationship, and so we're going to make a different class for each kind of dog."

They do this, and then make a dog the superclass or maybe as an interface. All the data about a dog is going to be getters and setters on the class. What is happening is they are a priority without any use case, plucking one column out of the spreadsheet and making it a static thing.

When I say static, I mean it is hard-coded. They are hard coding, Husky, Bulldog, Shih Tzu, Chihuahua and etc. They're hard coding those as subclasses, when it would have been...Let me say it's lossy. You're plucking out one thing, turning it static when it used to be dynamic.

Meaning that you just read it in from the spreadsheet, and you knew what it was. It was just a string. You're turning it into something static because in Java those classes are just part of the code. You're just doing that because it has an is-a relationship. You're missing out on all the possible things you could have done when it was just data.

When it was just data, you could do joins, you could do pivot tables, you could make it a drop-down box to select the different breeds. You could have another spreadsheet that represented the average weight of a certain breed when they're adult size, that kind of thing. You could join those two tables together.

There's all sorts of stuff you could do. It depends on your use case. I'm not saying you should go do all those things. You should look at the use case. What do we actually need to do with this data? I just find that in object-oriented programming, in these Java-Style class hierarchy programming...Not everyone's doing this.

I don't want any angry emails, like, "Oh, that's a terrible way to do it. Why are you shaming object-oriented programming?" I'm not doing that. I'm just saying from my perspective as a functional programmer, what people do is they have a priority before they've analyzed any kind of use cases. They pluck this one attribute out as somehow a static thing.

There are some use cases where this would be useful, but in a lot of them it's not. They have not proven that they have this use case before they do this. They just like the idea of creating an ontology where a Shih Tzu is a dog, and a dog has a weight. That's not your job.

Your job is to add features to this software. The features you have to add are like generate a report for the owner about how much money we're making or how many dogs of this breed we've serviced, and how many dogs of that breed. It's a totally different game.

What a functional programmer sees that as just another column, just another piece of data. There's no need to create this is-a hierarchy. There are some times when is-a hierarchies are exactly what you want, where you want polymorphism. As an example, you might have different date formats.

You want to say, "Well, these are all dates. I want to be able to treat them. I want to be able to convert all of these to a Unix timestamp. I don't really care what kind of data I have. I just want it to work. I don't want to have to write different code paths for every single kind of date there is. I just want it to be polymorphically, 'Give me the timestamp.'"

That's something that you have to do sometimes. That is using a specific tool for a specific use case. You don't actually have a table view of your data. Once it's in a table, man, you're good. That is the modeling. A sequel database table, you have this amazing high-level language for doing all sorts of cool operations with it.

To turn this into some class hierarchy, it's almost criminal. There, I said it. It's like you're throwing away the power that you have. My name is Eric Normand and this was a thought on functional programming. If you agree, if you disagree, please let me know. I love getting into discussions with people.

You can email me @eric@lispcast.com. You can also follow me on Twitter where I share all these thoughts in more bite-sized form. You can follow me @ericnormand. Also, I'm on LinkedIn if you want to get into that. Connect with me on LinkedIn @ericnormand. I share stuff there, too. Awesome. See you around.