There was no name calling; restrictive and prohibitive are simple adjectives and they seem applied correctly. There is implied dogma in the OP. Having an opinion about OOP either way is not mindless.
| [reply] |
"restrictive and prohibitive" are not examples mindless name-calling. Those are called opinions. So, as you can see, your question is loaded. Oh, did you mean "OOPolice?" If you took offense to that then maybe you rightly were called out for being one.
Now, if you had asked a better question, like "Why do you find this to be restrictive and prohibitive" then maybe we could have a more meaningful conversation. The answer is: because I find them to be unnecessary and a waste of my time. If Betty wants to reach into an object and access its internals, go right ahead. Freedom. As with pretty much any engine out there, you void the warranty when you break encapsulation but why should that stop you if you know what you are doing. These methodologies are for people who don't know what they are doing. And those people shouldn't be doing, they should be learning. | [reply] |
Pretty much any engine out there is by design hidden within some (usually restricted) compartment.
But this meditation isn't about making the engine inaccessible, it's mainly about designing in such a way that it's more obvious to Betty where the boundary between internal and external is, so it's harder to unintentionally abuse the internals.
| [reply] |
I just enjoy what works, in a particular application. (And all applications are different.) It so happens that I like to use things which help me put “all of the relevant code” into one place, and to “hide” things so that the compiler will detect situations where another piece of code (which I never would have found, among hundreds of source-code modules that I didn’t write) might interfere with another, or have a dependency on it, or introduce unwanted side-effects upon it.
Now, the Perl language is weak in that regard ... because of the legacy design of the language and because Moo/Moose are really “just puddings” that have been subsequently grafted onto it. But that can’t be helped and I’ll take what I can get. Gladly.
I suppose that I “lack dogma” because, most of the time, I am dealing with troubled, legacy systems which I did not write and for which the original programmers are long-gone. I’m trying to make improvements to a system that is chock-full of design problems which caused the original team to split the coop. OOP techniques work well for me, then. I am often trying to consolidate maybe-hundreds of redundant, sometimes not-quite identical, pieces of code that are scattered all over Casablanca, and to put them into just one place.
| |
