|Problems? Is your data what you think it is?|
Re: When to Use Object Oriented approach in Perl? (RFC)by sundialsvc4 (Abbot)
|on Aug 01, 2014 at 03:10 UTC||Need Help??|
Bottom line for me is ... I happen to find “the object-oriented approach” to be damned useful!! :-D
And here is why: “because you always know precisely where your data is!”
Q: “Exactly what piece of data is this piece of code supposed to manipulate?”
Instead of treating “executable statements” and “the data which the statements are to affect” as two separate things, the object-oriented paradigm makes things very, very easy: whenever your executable subroutines are invoked, “the piece of data that they are intended to manipulate” is implicitly known. You don’t have to monkey-around with “passing ‘the right thing,’ everytime and everywhere” to them, as procedure/function parameters that you must take care to provide “correctly.” Instead, the language itself does this for you.
“The language, itself” also shoulders more of the burden of determining whether-or-not these subroutines are “the right subroutines to call” in any particular situation. Instead of throwing that burden entirely upon you, as the application-programmer, the language bears much of it, through a clearly-defined mechanism of classes and inheritance rules which are easy to understand ... and to exploit.
“Damned useful,” as I said earlier, because it makes my chore easier.
Now, is there an equally-pragmatic down side? You bet there is! This crops up whenever you look at a particular bit of source-code ... and you simply can’t tell exactly what it’s gonna do ... and it actually makes a difference. (Example: you’re chasing-down a nasty bug, and you run into a fork in the road, and you cannot tell which direction the rabbit might have gone.)