OOP, FP, and encapsulating state

This article on medium.com has the flame title, Object-Oriented Programming: A Disaster Story. IMHO, a less-flamy but still accurate title would be, “OOP, FP, and the conundrum of encapsulating state.”

As someone who occasionally thinks of himself as an engineer as well as a software developer, I think you have to always look for what is the best solution to the problem, and sometimes that’s more along the lines of OOP, sometimes it’s FP, and sometimes it’s a hybrid.

For instance, when it comes to collection classes, I like the hybrid approach of the Scala collection classes where it appears that the functions are directly available on a collection instance, so I can write something like res = people.filter(age > 30). In other languages the filter function may not be directly available on a sequential collection class, so you have to import it and then write something like res = filter(people, age > 30). In either case you’re doing the same thing in the end, but the Scala approach “feels” better to me, and it’s also easier to read. (This example may just be syntactic sugar, but again, it’s easier to read, and the collections’ methods are a bit of a hybrid.)

As a better example of what I’m trying to say, OOP makes a lot of sense for rich GUIs, like Java Swing. Things like a JFrame, JDialog, JList, JTable, etc., all make a lot of sense in an OOP design. For instance, you create a JTable, the data is updated, users move columns around, and so on. OOP fits this very well.

Photo D8