And yet, I can easily argue that OOP is overkill for small to medium projects and takes up more lines of code to put functions into classes that will only ever be called once and don't really need to be a function, anyway.
While "redundant" coding may be typing the same thing up multiple times, there's also the folly of putting non-redundant code into a class file and then forcing it to be loaded every time that class is called, even though it will literally never be used in relation to that class ever again.
So if the answer to "will I ever use this function again?" is no, then, no, it doesn't belong in a class file. It'll just bog down the load times of that file. Significantly?
That's arguable.
I prefer KISS logic. "
Keep
it
simple,
stupid!"
OOP is great for keeping code organized, especially when working in teams. But... there is, actually, a performance hit. If you're the only one ever going to see the code, go ahead, stay procedural! Definitely! Well-commented code is just as important.
Undocumented object oriented code is twice as much of mess as a single file that I can at least use a search function on rather than having to cross-reference multiple other files to see what messed up where. I called a class? Did I call it with the right parameters in the right order? Inside that class I called a class? Inside that class I called another class? Good lord, just WHY? I could have done it in four lines of code and instead I just loaded multiple files and wasted seconds of processing time. I don't really care about readability or even copy-pasting if it means I understand it exactly where I'm using it. I don't have to chase an error down a mile away. I don't have to guess what the function I wrote in another file does exactly, because it's all right in front of me where I'm working on it.
I prefer to limit my classes to functions that interact directly with the database and other immediate functions that assist the ones that touch the database. I see classes as a necessary evil, and
not a solution to every problem. Imagine it like how the English language uses contractions. We drop a vowel, we shove some words together. Now imagine if w't'lk'dl'k'th's (we talked like this) - let's just shove all the words together and remove the vowels. You're supposed to guess what's there. That's what happens to my brain when I view object oriented code. I have to guess what's there. It's counter-productive to my productivity, even though other programmers love it.
If you're using a class inside of a class inside of a class - just - don't.
The worst part is that in the defense of "organization" (which I feel it isn't), it stabs performance by loading code it won't even run. It thinks it might, it's in the file alongside the function you called, so the rest of its all there, too. It took time to load that chunk. According to studies, it may have taken 600% longer than if you'd just written it without the spiderwebbing into classes.
If you can do it without, do it without. If you can't do without it (it NEEDS to scale), don't do without it (use objects!). But know when to draw a line (does it REALLY need to scale?). Don't do it for everything (do you know what this word scaling even means?), it IS, in fact, counterproductive. In every way - both in terms of organization and compile time. "Half your code
shouldn't be OOP baggage."
/end rant
tl;dr - Sick of people defending OoP blindly.