Saturday, August 12, 2017

Addressing The Problems With Object-Oriented Programming

YouTutbe is not my primary resource for learning new technology or paradigms.  I'm a Pluralsight-Lynda guy.  I still like to listen to presentations and lectures, though -  just to see what people are talking about in the real world.  There are a lot of conferences and interesting presentations posted on YouTube.
I'm an OO guy... still (I probably just lost all the functional devs, but I guess I'll be converting soon with React, we'll see...), but I do recognize the tricky issues inherent to object-oriented designs.  I was hoping this video might shed some light on what other devs do when they face similar problems.  I was in agreement with the early parts, but somewhere around that 30-minute mark, things started to change.  Then came the solutions, and that's where he completely lost me...  I think the solutions are worse than the problems.

My biggest issue with Will Brian's solutions, hands-down, is implementing long methods.  I don't even know where to begin.  They are hard to read - heaping loads of conditionals, variables, and state on you.  Accidentally breaking code because of semantic mistakes is a regular problem (unmatched curly braces, anyone?).  In Javascript, nested and inline functions lead to memory leaks.  It's impossible to reuse code that's bundled-up in another function.    It's just bad stuff.  I prefer the S.L.A.P. (single level of abstraction principle) approach, which basically boils down to new functions for every indentation.  I started doing this a few months ago, and it has saved tons of time in understanding flow, logic, and documentation (if you use good names).  I'll never go back to long methods.

Then there's the recommendation to use comments to explain what's happening in the long functions - another head-scratcher.  What's more common than an outdated comment?  I've learned to distrust them.  Instead, I follow the code.  Comments are useful when they explain why you've done something, but not to document what you've done.  Good function and variable names are better.

I'm also not sure what the problem is with "hopping" around code.  If functions are short, and scripts cohesive, you shouldn't be "hopping" far - especially if you copy-and-find.  Sublime even has a nice shortcut for specifically finding functions (control+R) - a very nice feature, indeed.  Hopping from script-to-script is painful, but as far as I can tell, it's just the price of decoupling.  I'm open to suggestions that eliminate tons of script files, but not if it means coupling.  There are always changes and rewrites; coupling makes them a nightmare.

But my intention here is not to antagonize Brian, or to try and poke holes in his coding philosophy.  Instead, I was inspired to speak my opinion on the ideas he raised.  It's a great reminder of the different types of devs we work with, and how we're all passionate about our ideas of good code.  "Object-Oriented Programming Is Bad" has nearly a half-million views, and it's only roughly a year and half old.  There are thousands of likes and dislikes - not bad numbers for a design pattern video.  Check out the comments - a lot of activity there, as well - all indicators that he has touched on very real issues.

Anyway, just sharing a few thoughts.  Let me know what you think about the video.