Ta Daaaaā¦Controversy! I know, I know, blasphemy, burn him at the stake, and all that good stuff. But hear me out.
I started developing in 2000, when developers were transitioning from CGI to PHP, and PHP had no concept of objects. I transitioned to Java, then took a break from coding. When I came back full force in the world of NodeJS, I restarted to code in a functional way.
As time passed, I discovered that ES6 had full support for classes to create an objects. It turns out that ārealā classes were introduced to help Java developers transition to JS. And Iām like, what? Why?
Anyway, I continued with my functional coding (using object as key=vale arrays), but kept seeing classes and objects popping up more and more. Then I saw code done by Java developers in NodeJS and I go, damn. OK, creating a super complex object out of a class just to get the name of a user from the DB was really overkill.
But I tagged along and did my functional thing.
Then I saw that the developers' APIs were in the range of 400 ms to 1000 ms. And I began to wonder what was going on. I read some articles about companies that moved from Heroku to AWS because their APIs were slow. And my skepticism grew, since Heroku uses AWSā¦Sure, Heroku packs more accounts on one server, but stillā¦Blaming it on the server didnāt seem right, especially when they went from 350 ms down to 250 ms to get some basic item information to display on a site. It seemed to me that the issue was with the code, rather than with the servers.
Initially, object-oriented languages were geared toward modeling the real world, but their benefits also extended to the ability to easily cache data from the hard drive into memory thanks to its design. With functional programming, you have to purposely do this.
With a local setting - a computer, smartphone, or anything that is constantly running and has a user in front of it - OO is definitely the way to go. Easier, better, and all that good stuff.
Back in the day, universities started teaching Java as the main language. This made sense back then, since the web was, you knowā¦ a joke, nothing serious, and learning CGI or PHP and building sites were just hobbies.
But as Iām writing this, we all know what the web turned out to be.
I remember the debate over adding support for Objects into PHP. Two camps popped up: those who were excited about the prospect, and those who didnāt see the point. The main idea behind introducing Classes into PHP was to attract Java developers to PHP, and to help them make the transition.
Side note: The word transition implies that you start doing it one way, and then you learn the right way. But we know how the human mind works; if it feels comfortable, we stick with it.
The same thing happened with JavaScript in version ES6 of the standard. JS already allowed you to build objects. Hell, you could make a full-fledged object in more ways than you have fingers on your left hand. But they introduced the concept of a Class, a structure to describe how to create an object, which is 1:1 how it's done in Java. The syntax is exactly the same, which I like, since it's very clean and simple to work with.
Why did they do this? Literally to help Java developers make the transition to JavaScript. And how do people code for the web today? With Classes, because of muscle memory, not because it make sense.
If you were creating a mobile app, you would have a User Class that would be loaded into memory when the app started, and the constructor would kick in code that would load some user data from SQLite, such as the Name, Last Name, and Avatar. Of course, the Class would have functions to return the name, last name, and avatar, along with reversing the text and inverting the image colors as a joke for Primas Aprilis. Heck, even functions to update the data.
This information would stay in memory, so you wouldn't stress the built-in storage every time you have to display this information, and it would be faster. This seems obvious and just makes sense.
Here, you do the exact same app, but instead of being on a mobile device it's done as an API written in NodeJS and connected to a nice database. Every time a user visits your site, you have an API called /me, which you query every time you want to show the user data (You can cache this in the browser it self, but that's not the point right now).
With back-end code, you canāt take advantage of the memory caching an object, since each request lives until the connection closes, and there is no state that you can take advantage of (There is, but again, not the point).
In this case, you are only left with the concept of representing data in a ānaturalā way.
I believe that in the back-end world, the benefit of a Class is virtually zero. Once you start getting tens of thousands of requests per second, your code is just literally creating and destroying object at each request...For what? Because you are used to coding this way? Seems like a big waste of resources to me.
By the way, did you realize the I've just been talking about the back end rather than the front end all this time? Bazinga! ;)
If you did the /me API in a functional way, when you received a request, you would just make a simple selection from the DB, return back the result as JSON, and that's it. This is the whole request. You don't need to create and then destroy anything. If you want to have some sort of transformation for Prima Aprilis, you can make an additional promise in the chain that will trigger on the right date or when you pass an argument in the URL. Done. The API will just fly.
Yes, when Iām dealing with a situation in which something or someone stays indefinitely connected to my back end. For example:
I had this project in which I was asked to wrap a modern RESTful API around an access control device that was designed more then 15 years prior, and the only way you could communicate with it was with a raw socket connection and a custom protocol. Once connected, the device stayed connected as long as the connection stayed up or the device had power. You could see that we had an active and persistent connection to the server. Here, I made a nice Class that mimicked the device connected to the server. In this case
When a device connects, the code creates an object out of my Class. I then query the device to ask for any additional data that's needed, and part of the data stays in memory.
On the other hand, the API part of the server is just functional. The API has access to all of the connected objects/devices, and I just query the object for the right data. For example:
Ask an API endpoint to give back the number of doors it controls, and the API uses a function of the Device Object to retrieve that number.
If you have to open a door remotely with the API, another function would fire on that Device Object, and that request would then...
- ...be translated inside the object in the special protocol
- ...send the request to the device
- ...wait for the response
- ...parse the response
- ...translate the response form that custom protocol in to JSON
- ...and send it back to whoever made the API request.
I believe this was one of those situations in which I was happy that JavaScript had Classes, because I was able to make a nice server that just works beautifully, and Iām proud of it.
This situation is perfect Object Orientism š. I treat OO as just another tool that I have at my disposal to solve a specific problem in a specific way. And use functional programming to solve another problem with the right tool.
Do you still think OO is a way of coding, or is it just another tool in your tool box?
If you enjoyed this project, please consider giving it a š. And check out my GitHub account, where you'll find additional resources you might find useful or interesting.
This project is brought to you by 0x4447 LLC, a software company specializing in building custom solutions on top of AWS. Follow this link to learn more: https://0x4447.com. Alternatively, send an email to hello@0x4447.email.