Is it worth converting my functional JavaScript code to an object-oriented design?

Question

I'm currently building a small web application that includes a fair amount of JavaScript. When I was prototyping the initial idea, I just hacked together a few functions to demonstrate how the application would eventually behave intending to go forward re-writing the JavaScript in an object-oriented nature.

Now that I'm getting into the implementation phase, I'm finding that creating object-oriented JavaScript for the sake of being object-oriented seems overkill - the project isn't likely to require any major modifications in the future that would warrant and object-oriented design. Instead, I'm finding that a set of concise, cohesive functions are working well.

So, with that said and with attempting to adhere to the KISS principle, when a set of functions are providing a suitable solution to a problem, are there any other reasons worth considering to convert my code into an object-oriented design?

Answer 1

No, let it be and move forward - that is more productive in my view .

Answer 2

No, although I personally find OOP more tasty, it is a means to an end, and not an end in itself. There are many cases where procedural programming makes more sense than OOP, an converting for the sake of converting, could be, as you said, overkill.

Answer 3

If your code is well structured, well laid out, and well commented, and does the job that is required of it, then messing with it for any reason other then to add features is ill-advised.

While it might be nice to say that the program is nicely OOP etc, if it doesn't need to be changed to work then I would definetely leave it as it is.

If it aint broke, dont fidgit with it :)

Answer 4

Treat it as legacy code from now on. When you want to change something, refactor it so the code becomes easier on the mind. If you need a bit of OOP, use it. If you don't, don't.

OOP is a hammer, please don't treat a screw-problem as a nail.

Answer 5

If it works, and it's easy to maintain, I wouldn't bother converting it for convertings sake. There must be more interesting things to do.

Answer 6

If this code is already implemented and won't require maintenance or - better yet - upgrades, stick with it. If you are going to implement it now and it could get complex, consider the OO approach.

Experience has shown me that it's pretty easy to write and maintain procedural code while complexity is low, but after a certain threshold it starts getting exponentially more difficult to increase complexity while using procedural programming, whereas OOP, although harder to begin, keeps complexity much more manageable.

Bottom line: if the task is simple enough or has already been implemented, keep it simple. If it might grow more complex, consider OOP.

Answer 7

Just bare in mind Objects are rather expensive to create in javascript.

Keep construction of objects to a bare minimum.

Answer 8

I would say that it is still worth reviewing your code before making a decision. The obvious downside to "re-writing" code is that there is a testing cost to ensure that your code works the same as before. Do you have any Unit tests? If not, then your testing cost is even higher. So in general, I'm against re-writing working code unless it serves another end, which is to allow you to more easily write new functionality that is now required (i.e. refactoring common functions, etc.)

HOWEVER, any time a person says "I hacked together", I suggest it is always worth a second look at your code. Why was it hacked together in the first place? I know plenty of people say that Object Oriented code isn't an end in and of itself, but it is a methodology that after while doesn't have to be thought about either. You just sort of naturally start doing it.

Maybe your js is relatively simple, and therefore OO scafolding is truly extra overhead. Fine. But I still suggest that you should always code review (and especially have someone else review) any code you call "hacked". Perhaps it was a Freudian slip... but it did slip.